A Microsoftot okolják a nagy felbontású állóvízért

Ha jól mûködik és elég szép lesz az eredmény akkor kiegészítem majd egy bináris kereséssel. Így nem kell összehasonlítani minden egyes mintát, csak a teljes adatbázis logaritmusának mennyiségû mintával. Ami csak pár tíz, vagy száz mintát jelent blokkonként. Szerintem meg lehet csinálni gyorsra, de az már a végsõ fázis lenne, az optimalizálás ;)

Igen, pontosan ezt (2.) keztem én is megírni 16 évvel ezelõtt. Csak nagyon lassú (fõleg akkor) a mintakeresés, mármint kellõ hatékonysággal.

Akkor most már megtanulhatnád használni a "válasz erre" opciót is... :)

"Érdekes egy dolog a matematikában,hogy amit be tudsz bizonyítani, annak bebizonyítható az ellenkezõje is."

Ez azért picit kiüti a biztosítékot, a negáció természetébõl adódóan olyan (ilyennek találtuk ki), hogy ugyanazt lehessen leírni vele, mint az eredeti állításokkal. Így ebben semmi érdekeset nem látok :)

hát, én a jpg-et nem szeretem annyira, mert erõssen látszanak benne a frekvencia jelek, a DCT frakvenciákra bontja a blokkot, és amúgy is, egy blokkot kb 12-18 bájtal ír le, az ennyém meg csak 9 el, ha nagyon részletes a hely akkor többel.

Azért agyalok egy jó minõdégû veszteséges dolgon is, mert tudom ,hogy real time ban nem lehetne lossless videot kitömöríteni az én eljárásommal, ma még nincs olyan gyors proci, fõleg HD tartalom esetében.
Egyébként egy jó minõségû tömörítõ, és a lossless között úgy sem lehet észre venni lejátszás közben a különbséget a kettõ között. De az egyik lehet 100 kisebb is.

És egyáltalán minek agyalsz a veszteséges képtömörítésen, ha már úgyis megvan az ultimate, bármit bármikor bárhányszor veszteségmentesen tömörítõ algoritmus? :S

Vagy mégse bízol benne annyira?

Egyébként finoman szólva kétlem, hogy a blokkhasonlóságos dolog jobb eredményt adna, mint a JPEG. Végsõ soron az is azt mondja, hogy milyen blokkhoz a leghasonlóbb, csak nem egy lista elemeire mutató sorszámot, hanem a blokkot elõállító együtthatókat tárolja.

Nem, ez félre értés, a képeket nem fraktál tömörítéssel csomagolom be.
Hanem, lesz egy nagy adatbázis ami teli lesz több ezer 8x8 , meg más méretû blokkokkal, a blokkok különbözõ mintákat tartalmaznak majd, és egy képet ezekbõl épít fel a program, a tömörített állományban meg csak az adott blokk sorszámát tárolom el, és egy kis infót ami azt mondja el,hogy ezt a kis mintát, hogyan transzformálja, mondjuk növeli az intenzitás fokot.

A fraktált már a veszteség mentes eljárásnál használnám fel.
Fogom az adat streamet és kiveszem belõlle azokat a mintákat amiket ismer az algoritmus és nagy valószínûséggel megtalálható, a fennmaradó adatokat ugyan úgy írja le, csak már nem lesz benne az adott minta, vissza álításnál ,meg egyszerûen a mintákat visszarakja az adatsorozatba, mint egy vésõ, bele ékelõdik majd a bitek közé, vissza álítva az eredeti elrendezõdést.
De ami fontos,hogy a minták kiszûrése után ha megint megvizsgálod a biteket, akkor megint újabb mintákat találsz meg bennük, és ha ezt rekurzívan ismétled akkor annyival csökkentheted a méretet, amennyivel akarod, vagy amíg el nem fogynak a bitek. A minták mindig újra és újra ott lesznek.

ezt már évek óta látom megjelenni az sg-n. vki mindig kitalálja, h pár hét/hónap múlva képes lesz eltárolni egy HD-filmet 20MB-on belül...

(csak tipikusan az van, h minden nap holnapjára van kitûzve a határidõ)

u.i.: konkrétumok(részlet a source-ból, screen-shot, stb.) nélkül nagy dolgokat tényként beharangozni elég bulvár-dolog...(kivéve ha nem megrendelõ-kivitelezõ a felállás az itteni peer2peer helyett)

Üdv!
Frayer:Utánaolvastam a témának és hirtelen találtam is vmi-t ami sztem elgondolkodtató:
http://dspace.lib.unideb.hu:8080/dspace/bitstream/2437/2385/1/diplomamunka.pdf
Idézném a lényeges részt:
"Fraktál alapú képtömörítés
Egy szó többet mond ezer szónál, szoktuk gyakran mondani. Nos, általában jóval több helyet
is foglal, egy 1024 × 768-as felbontású, 32 bites színmélység½u tömörítetlen kép mérete közel 3
megabájt tárhelyet foglal el. Így aztán manapság, amikor már a legolcsób mobiltelefonokban is
beépítet megapixeles kamerát találunk, fontos, hogy mind újabb, nagyobb hatásfokú adattömö-
rítési (els½osorban kép- és hangtömörítési) módszereket alkossunk. Jobb tömörítési arány érhet½o
el, ha a tömörítés során el½oállt képt½ol nem várjuk el, hogy pontos mása legyen az eredetinek.
Egészen kis eltérésekr½ol van szó, akár olyanokról is, amelyek az emberi szem számára látha-
tatlanok maradnak. Az ilyen elven m½uköd½o módszereket veszteséges tömörít½oknek nevezzük.
Jelenleg három technológia uralkodik a veszteséges tömörítés területén : a vektor kvantálásnak
nevezett módszer, a diszkrét koszínusz transzformáció (DCT), és a fraktál alapú képtömörítés.
Az els½o módszer esetén a képet kisebb részekre osztják, és egy ún. kódkönyvb½ol (codebook)
választanak hozzá megfelel½o reprezentánst. A diszkrét koszínusz transzformáció a képeket egy
másik térbe (az ún. frekvenciatérbe) konvertálja, majd az így kapott értékeket megfelel½o módon
kvantálja. A harmadik esetben a természetben el½oforduló alakzatok (bizonyos mértk½u) önhason-
lóságát használja ki. 1988 Barnsley kidolgozott egy módszert, amely digitális képek jó hatás-
fokú tömörítését tette lehet½ové IFS-ek felhasználásával. A módszert sokan továbbfejlesztették,
jelenleg is igen sok változata ismert. A technika még csak gyerekcip½oben jár, a lehet½oségek
majdhogynem beláthatatlanok. Barnsley alapgondolata az volt, hogy ha néhány nagyon egy-
szer½u transzformáció segítségével bonyolult, a természetben is el½oforduló alakzatok sokasága
állítható el½o, akkor ez felhasználható az ilyen alakzatokat ábrázoló képek tömörítésére, hiszen
a képpontok helyett elegend½o a képet el½oállító transzformációkat eltárolni, ami drasztikusan
lecsökkenti a szükséges tárhely méretét. Azt is észrevette, hogy az egyes iterációk fixpontja
semmilyen módon nem függ a kezdeti képt½ol, így az iteráció tetsz½oleges kiindulási képpel el-
indítható. A kérdés csak az, hogy tetsz½oleges kép el½oállítható-e IFS-ek segítségével, vagy meg
kell elégednünk bizonyos képek nagyarányú tömörítésének lehet½oségével. Sajnos a válasz nem-
leges, vagyis a képek többségéhez nem adható olyan IFS, amelynek fixpontja maga a kép lenne.
Ez logikus is, hiszen pl. egy emberi arc egyáltalán nem önhaonló, tehát a szerkezete nem frak-
tálszer½u. Márpedig az IFS-ek segítségével leginkább fraktálokat lehet el½oállítani (vagy csakis
azokat, ennek eldöntéséhez pontosan kellene definiálnunk a fraktál fogalmát – pl. fraktál-e egy
négyzet?). Szerencsére van megoldás: osszuk fel a képet egyforma méret½u kisebb tartományok-
ra, és ezen tartományokat próbáljuk meg összevetni egymással. Ezt a technikát Arnaud Jacquin
dolgozta ki, és az ehhez felhasznált speciális iterált függvényrendszereket PIFS-nek (Partiti-
oned Iterated Function System) nevezik. A módszerek jól kidolgozott matematikai alpokkal
rendelkeznek, tekintsük most át ezeket."

Gratulálok Frayer. Szép flame-et csináltál. :)

Csak kurv@ nehéz lesz megtalálni a megfelelõ paramétereket. ;)

Na persze nyilván te sem az egész képre keresel egy ilyen paraméter-csomagot, hanem a fellelhetõ fraktál-alakzatokat próbálod megkeresni. De ezt is nagyon nehéz jól csinálni, és nagyon lassú. Szerintem a te próbálkozásod egy a sok közül, és évtizedek alatt fog ez a dolog odáig fejlõdni, hogy már elég jó lesz. (Persze nem biztos.)

Szal pl. a fraktálok felfedezése elõtt mutattunk volna egy matematikusnak egy szép Júlia-halmaz részletet, nyilván jól bebizonyította volna, hogy az nem írható le egy koordináta párral, és 1-2 plusz paraméterrel.

Ha jobban megnézed, láthatod, értettem, hiszen külön tárgyaltam a matekatikai "lehetetlen"-séget, ahogy te is.

No és honnan tudod, hogy az említett személyek bizonyítása helyes?

Te nem érted amit én mondtam. Régen azt hitték hogy pl a nap csak 5000 éve van mert szénbõl van és kiszámolták hogy ennyi ideig elég a szénkészlete. Fizikailag lehetetlennek tartották hogy régebbi legyen. Azóta kicsit kibõvültek az ismeretek és már fizikailag sem tartjuk ugye lehetetlennek.
Na de 2x2=4 akárhogy is nézzük a matematikai szerint. Vagy ki lehet dolgozni teljesen új matematikát (néhányaknak sikerült is pl bolyai). Na most ha be van bizonyitva hogy 2x2=4 akkor abból akkor sem lesz 3 ha jobban optimalizász, assemblyben irod meg a szorzást vagy hosszú kommenteket irogatsz az sg-re. Erre mondtam én hogy van ami matematikailag lehetetlen meg van ami fizikailag. Nem tudom érthetõ voltam-e. Lehet hogy rosszul használtam a szavakat és inkább azt kellet volna irnom hogy van ami elméletileg lehetetlen meg van ami gyakorlatilag. A gyakorlati lehetetlen általában lehet überelni, az elméletit ritkábban

Ehez nem is kell messze menni.
Ott van a russell paradoxonja. Másnéven borbély paradoxon.
Russell Paradoxon

Ohhh, minõ véletlen, olvasd el a wiki cikket és érdekes módon itt elõ bukkan Cantor neve. Biztos én írtam oda :) Meg én találom ki itt a néphülyítõ dolgokat. Na persze.
Az életben semmirõl nem állíthatunk biztosan semmit.
Hidd el nekem, hogy az a matematikai model amit most használunk csak egy igen jó közelítése a világ leírásának. Szerinted annó miért vezették be a komplex számokat? Mert hibás volt a matematikai model, és nem tudtak vele számolni a fizikusok. Ott van a -1 gyöke. Mindenki tudja hogy negatív szám négyzete pozitív, mivel negatív szorozva negatívval az pozitív. De mégis van hogy ez így nem álja meg a helyét. Mert kell hogy létezzen a mínusz számok gyöke, máskülönben nem lehetne megoldani sok valós életbõl vett problémát, egyszerûen nem lehet rá felírni megfelelõ formulát. Ezért bevezették a komplex számokat, aminek az lett az eredménye,hogy megjelentek a fraktálok és a káosz elmélet.
Szép lassan rájövünk hogy az egész világ egyetlen egy fraktálnak más más különbözõ "látképei".
Érdekes egy dolog a matematikában,hogy amit be tudsz bizonyítani, annak bebizonyítható az ellenkezõje is.

"Ugyanugy mint az örökmozgó. Nem azért nem lehetséges mert nem tudok elég erõs mágnest épiteni, vagy elég nagy rakétát stb, hanem mert elméletileg sem lehetséges."

Látom, nem érted, hogy ami fizikailag lehetetlen, az elméletileg lehetetlen. Hiszen a fizikai elveket is mi találtuk ki, a mi elméletünk. Sokmidnen van, ami ellentmond az elveknek, mégis úgy van.

Persze a matematikai elvek már erõsebbek, de a matematika sem mindenható, abban is vannak paradoxonok.

Amit itt leírsz, az szinte egy-az-egyben a jpeg tömörítés. :)

Ha mûködni fog, nem kell majd semmit "kidumálnod".

"- "tesztek" (elágazások) nélkül nem lehet olyan programot írni ami csinál is valamit"

Mondjuk a feltételes végrehajtás és az elágazás nem ugyanaz, lásd Static Flow Control vs. Dynamic Flow Control.

@Frayer
Sok sikert a munkádhoz, de szerintem amíg nincs valami kézzelfogható eredményed, addig nincs értelme beszélni a dologról. Így olyan fogarasiárpádos az egész, modernebb kiadásban :)

nemcsak 8x8 as blokkok lesznek, lesznek 16 osok, és 4x4 esek, attól függõen, milyen részletes az adott terület. Így mindig optimális lenne a letárolt kis cella.
De errõl még ne beszéljünk, nemtudom hogy milyen is lenne igazából.

"nem szeretem látni ha a videóban kis néygzetek jellenek meg"

Ezt elég vicces olvasni annak fényében, hogy a megálmodott videókodeked úgy kezdõdik, hogy 8*8-as kockákra bontja a képet.

Frayer tök mindegy, hogy mit mondasz, megváltást, vagy hülyeséget, itt nem lehetsz okos, nem azért amit mondtál, hanem azért, mert itt senki nem lehet az. Ez van. MAGYARORSZÁG. Tudod. De mindegy, csináld azt, amiben hiszel, legalább addig is csinálsz valamit és ez a fontos. na csá. megyek megírom a direct x 18-at pascalba.

> Egyébként egyedül nem tudnék megcsinálni egy komplett video kodeket, ehez tényleg egy jó csapat kellene

Nem csapat kell hozza hanem egy jo otlet meg szabadido.

Én ha egy mesterséges furier transzformált vagy wavelet csomagokkal létrehozott és egy természetes mintákon alapuló bázisok közt kell választanom akkor én a természetes mintákat választanám, nekem nem jön be a bekockásodás, nem szeretem látni ha a videóban kis néygzetek jellenek meg.

Ez a veszteséges dolog egy másik kategória, ehez még hozzá sem kezdtem.
De remélem ha belekezdek azt fogom majd látni,hogy nem lesznek artefaktok.
Tudom,hogy önmagában amit leírtam az kevés.
Ennél sokkal többet fog majd csinálni, csak az alapját írtam le.
Ennél tovább még nem mennék, mert nem akarok oldalakat írni errõl, meg teli van az oldal szkeptikusokkal, most úgy sem számít mit gondolok, majd csak a kész végeredmény. De akkor már biztos nem fogom elpofázni a megoldást. Egyébként egyedül nem tudnék megcsinálni egy komplett video kodeket, ehez tényleg egy jó csapat kellene, és pár hónap.
De a "food/lfg" programot meg bírom csinálni egyedül is, csak pár ezer sor lenne a forráskódja c++ ban, ha ez megvan, lesz értelme tovább lépni a video tömörítésre.

> Pont errõl beszéltem,hogy fogok egy 8x8 as blokkot és azt egy a leghasonlóbb mintával írok le, így elég lesz annyi információ erre a blokkra ami leírja az adott blokk sorszámát egy több ezer elemû adatbázisban

Ezzel az a borzaszto nagy gond, hogy alig fogsz hasonlo blokkokat talalni. (tapasztalatbol mondom) A kerdes csupan az, hogy mit nevezel majd hasonlonak, ugyanis ez a tureshatar fogja majd nagyban befolyasolni a tomoritesi arany ill. minoseget. Ha ezen a vonalon haladsz egeszen biztosan nem jutsz tulzottan messzebb mint a jelenlegi megoldasok. Ne erts felre, nem akarom a kedvedet elvenni - sot talan inkabb osztonoznelek - de ezek mar agyonvissza tesztelt dolgok es bizonyitottan korlatosak.

> A bázis minták amik azt a referencia adatbázist építik fel pedig csak tömörítetlen vagy lossless képekbõl építkezne.

Akkor pontosan annyi mintat kell venned mint amennyibol a teljes tomoritendo anyag all?

En mindenesetre nem ezen az uton haladnek, hanem kiindulnek abbol, hogy a kepeknel, videoframeknel az egyes szincsatornakon a keppontok fuggvenyszeruen kovetik egymast. Csinalok egy hullamtomoritest egy frame kulonbozo szincsatornaira majd erre raeresztek egy pl. huffman algoritmust ami igy nagysagrendekkel hatekonyabban fogja tomoriteni, mint egyebkent nyersen es meg mindig ott vagyok, hogy loseless tomoritettem egy framet. Ebbol mar el lehet indulni egy veszteseges algoritmus iranyaban is.

Elég legyen annyi,hogy majd használhatod a programot egy módosított gpl licensz alatt ingyen.
Szerinted olyan hülye vagyok hogy mindent kiteregeteg a mûködéssel kapcsolatban?
Persze amint elkészültem, majd a forráskódot közzé fogom tenni.

Frayer téged kár gyõzködni mert tökéletesen mellébeszélsz, de annyi baj legyen.

Arra kérnélek hogy az általad említett eredményeidet publikáld valahol, ez nem sok idõ így a vizsgázásban sem fog megzavarni, viszont szerintem mindenkit megnyugtatnál vele :)
(mondjuk a "száraz teszt logikai emuláció" kimenetét :)) )

Adós vagy még egy pár képlettel és linkkel amik felett úgy látszik elsiklottál, de erre számítottam, szóval eltekinthetünk tõle ;)

Majd ha netán véletlenül el is készülne, és a nobel bizottság leszopja mgát tõle, akkor talán elhiszem hogy ez egy létezõ dolog, addig csak a kanálgörbitõs urigellerrel és az ufós danikennel tudom egy lapra tenni komolyság terén a dolgot. ^^

Igen igen, én is erre gondoltam mikor veszteséges tömörítésrõl beszéltem és hogy lásd hogy nem kamuzok, egy másik topikban pont ezt vázoltam fel már vagy egy hónapja.
tömörítõ program
Pont errõl beszéltem,hogy fogok egy 8x8 as blokkot és azt egy a leghasonlóbb mintával írok le, így elég lesz annyi információ erre a blokkra ami leírja az adott blokk sorszámát egy több ezer elemû adatbázisban, minden minta a lehetõ legjobban különbözne egymástól,hogy a legváltozatosabb blokkokat is nagy közelítéssel meg lehessen adni, és azért lenne artifakt mentes, mivel a természetes képek, azaz nem mesterségesen elõálítottak, hanem a szabadban fotózva létrejöttek nem tartalmaznak artifaktokat. A bázis minták amik azt a referencia adatbázist építik fel pedig csak tömörítetlen vagy lossless képekbõl építkezne. Ezért a természetes alakzatokat a képen, vagy mintákat nagyfokú közelítéssel meg lehet adni nagyon kis helyen, DE a nagyon statikus jeleket amik nem fordulnak elõ a természetben, azt viszont rossz közelítéssel adja meg, mint a hangyák a tvben mikor nics adás.
Persze maga az az algoritmus amirõl most szó volt eddig az más, és ehez nincs köze.
Ezt csak azért találtam ki, mert úgy gondoltam, hogy minden egyes video framet betömöríteni az nagy munka lenne , a kitömörítés szintén, és ezért percenként több gigabájtos adatot kellene feldolgozni, ma még nincs olyan processzor. Szóval elõbb kell egy vékony, gyors jó minõségû veszteséges eljárás amit tovább lehetne csökkenteni ezzel a food/lfg programmal. :))

Talan itt az SG-n is volt az a talalmany, hogy a fenykepek helyett az igazolvanyokon eleg lenne par byte-ban letarolni az egyen arcberendezeset, amit egy progi egy fantomkep szerkeszto adatbazis-szerusegbol le tud generalni.
Sok ertelme nincs mert manapsag, gyak korlatlan a tarolokapacitas. 50 evvel ezelott jo lett volna:)

Szal, ha talalunk egy olyan mintahalmazt, ami jo kozelitessel alkalmazhato a valos video anyagra, akkor belathatatlan "tomoritesi" lehetosegeink vannak. Persze sima zajra, amikor hangyak harcolnak a kepernyon nulla szazalekos tomoritest tudnank csinalni:)
Masreszt az a jo ha minnel zajtalanabb a kep, mert annal konzebb felismerni a mintakat ugye.

Azért mert ahogy belinkeltem azt a másik topicot, ott már 500 ebben jártas/ez a szakterületük ember MATEMATIKAILAG bebizonyitotta hogy lehetetlen. Itt nem arról van szó hogy valami fizikailag lehetséges vagy, hanem arról hogy elméletben sem lehetséges. Ugyanugy mint az örökmozgó. Nem azért nem lehetséges mert nem tudok elég erõs mágnest épiteni, vagy elég nagy rakétát stb, hanem mert elméletileg sem lehetséges. Ráadásul a tömörités szintiszta matematika független bármiféle fizikai dologtól számitógéptól vagy bármitõl. Csak a matematikától függ.

Persze hablatyolni én is tudok, sõt nekem már megvan fejben az örökmozgó terve is, sõt tulajdonképpen meg is van épitve a modell, már csak egyetlen ici pici apróság van hátra (de ez biztos nem tart tovább 1-2 hónapnál megoldani) mint egy aprócska elem amibõl sosem fogy ki az energia. de én egészen biztos vagyok benne hogy néhány hónapon belül sikerül erre az apróságra is megoldást találni és akkor enyém a nobel dij (tényleg apróság hisz maga a gép 1 tonnát nyom és két méter magas...)

:DDD

hmm kicsit elmerülök a témában, hogy a kicsit ködös részekbõl is felfogjak valamit, de nemtudom... én eddig az SG-rõl csak roliiikát ismertem, aki halálközeli állapotba hozott, olyanokat röhögtem, Frayer lehet, hogy végülis nem tudja megvalósítani az ötletét (megint: miért ne?->igaz, problémák, etc, de akkor is), de az már 1 jó dolog, hogy elgondolkodott rajta, sokat tanulhat belõle. mondom, én ezért imádtam a programozást: marha sok fejtörõ, aminek egyrészt nem csak 1 megoldása van, másrészt meg fel kell ismernie a programozónak a (saját) hibákat is..

Frayer, ha vége vannak a vizsgáidnak (most nemtom, a félévesekre gondoltál?), akkor térjünk már vissza egy külön SG fórumtopicban erre, addigra én is végzek velük, meg utánaolvasok, meg gondolom lesz még 1-2, nálam jóval többet tudó ember is, aki néha belekukkant a topicba, vitatkoz6unk..

Én nem azért írtam ide, hogy bejelentsem hogy dolgozok valamin ami talán mûködni fog, talán nem.
Az a helyzet hogy a dolog mûködik, tehát nincs kétség a felõl,hogy lehetséges e vagy sem, ez már letudva. Most amint vége lesz a vizsgaidõszaknak, rögtön neki állok egy winen futtatható programnak.
Nemsokára elkészül és bárki megnézheti, akik itt most szkeptikusok, olyan nagy filet és azt hoznak amit akarnak és õk is tömöríthetik be, én nem nyúlok hozá.
Úgy lenne a legkorrektebb a tesztelés ha hozol egy dvd-t azt berippeljük egy iso- fileba "mivel elõsször csak egy filet lehet tömöríteni, így hamarabb készen leszek a programmal" azt az iso-t becsomagoljuk x számítógépen, az eredményt felírjuk egy papír cetlire, és bepötyögjük y gépen és várjuk az eredményt.
Én tudom hogy mûködik, csak nem értem, hogy ez miért lenne ez lehetetlen?
Miért? Nekem nem sikerülhet ilyet csinálnom, ha nem 200 as az iq-m, vagy nem vagyok milliárdos és mert az sg-t olvasom?

Dolgozzatok rajta. Nagyon jo otlet. Nem szamit mennyit dolgoztok rajta csak ti legyetek az elsok. Ti meg ne mind tamadjatok az otletet, inkabb tamogassatok sokkal tobbre mentek vele <#vigyor2>

Én drukkolok a kollégának!Bár szerintem hozzám hasonló lehet.
Nekem is vannak néha komoly agymenéseim,szuper nagyszerû ötleteim,amiket nem is értem mások miért nem csinálták még meg.
Aztán amikor elkezdem kidolgozni rá kell jönnöm hogy nállam sokkal okosabb embereknek sem ment,néhány apró lényegtelennek tûnõ probléma miatt.

Viszont amennyiben valóban képes lennél megcsinálni nem ártana valami pártfogó aki valóban meg tudja védeni a találmányt és téged!
Ugyanis én úgytudom bár lehet rosszul hogy a szabadalmi jogok elismertetése nem olcsó dolog fõleg ami az egész világra vonatkozik.
És egy kis embert innen az istenháta mögötti kis országból egy pillanat alatt behúzzák a multik,katonaság,stb azt keresel vele egy kalap sz..t.

Minden esetre hajrá!persze,csak ha nem hülyíted itt a népet!

Emlékszem egy srác engem kb. fél órán keresztül arról oltott, hogy segítsek neki megcsinálni az általa tervezett örökmozgót. Rég otthagytam volna, csak azért beszéltem vele annyi ideig mert még soha az elõtt nem találkoztam a naívság és a tudálékosság olyan szintû megnyilvánulásával. Az az érzésem, hogy újabban a srác egy szupertömörítõn dolgozik, legalábbis a stílus nagyon hasonló:DDD

Holnap már a kínai titkosszolgálat által alkalmazott hekkerek fogják feltörni az esgé szervereit, hogy megszerezzék az ip címedet. Onnan már sima az ügy. Nem vagy biztonságban testvér, én mondom.
A megszerzett információkra meg ráeresztenek 100-200db (ott így mérik az embereket) kis sárkány programozót és matematikust.. Lehet hogy a kínaiaknak elõbb lesz mûködõképes algoritmusuk mint neked.
<#banplz>

"magyarországon"
->
"Magyarországon"<#wow1>

" Hanem csak azért kétlem mert ha ilyet meg lehetne csinálni már rég megcsinálta volna valaki. Ez szerintem nyilvánvaló."

Szerintem ne ebbõl induljunk ki. Hiszen akkor soha semmit nem találnának ki (fel). Viszont ettõl függetlenül kételkedem ebben az egészben...

Frayer: szerintem elég sok cég/fejlesztõ foglalkozik tömörítéssel ha nem is magyarországon. Elég nehéz elhinni, hogy ilyen óriási ötleteid vannak úgy hogy még be sem fejezted a tanulmányaidat. Persze ettõl még lehetnek, de meg kell értened hogy sokan kételkednek...és az hogy egy ilyen topicba csak úgy felveted a dolgot, már önmagában furcsa. Egészen addig amíg valami mûködõ cuccot nem mutatsz fel, szerintem hanyagolni kellene a dolgot. Anélkül is kérdezhettél volna forrásokat hogy kvázi konkrétan elmondod mit is akarsz csinálni, és akkor nem kellene hallgatnod a sok szkeptikust.
Mindazonáltak kíváncsi lennék, hogy hol és mit is tanulsz pontosan, hanyadéves vagy és esetleg hány éves. Persze nem muszáj válaszolni, csak érdeklõdöm.

Én már láttam olyan játékot ami kb. 90kb és 300mb lesz miközben futattod. Csakhogy ezt úgy érte el hogy minden textura, minden hang lényegében egy algoritmus volt. Nem tartalmazott lényegében semmit. Meg is kérdezték tõlük hogy nem tudnak e rendes tömörítést csinálni de aztán írták hogy nem nagyon mert amit õk csináltak játék, abban csak olyan dolgok voltak amit függvényekkel meg tudtak csinálni.

pl.
tömörítsd be a bibliát, és aztán egy karakterszámra megegyezõ doksit de csak A betû legyen benne. Hát a másodiknál igen jól lesz a tömörítés az elsõhöz képest.

Szerintem csak olyan dolgot lehet hatalmas hatásfokkal tömöríteni amit le lehet vezetni egy képletre, de szerintem ennek az az ára hogy ne legyenek benne "kiszámíthatatlan dolgok". És hát egy film csak ilyenekkel van tele.

Én nem értek a témához ez tény, ezért nem is annyira a leírtak alapján mondom hogy tévedsz, és feleslegesen pocsékolod az idõd. Hanem csak azért kétlem mert ha ilyet meg lehetne csinálni már rég megcsinálta volna valaki. Ez szerintem nyilvánvaló.

De ez csak szigorúan szvsz.

Cél hardware engem is érdekelhet majd :) , De most nem keresek melót.

Ha tényleg célhardver készülne rá, mondjuk a procikba beépítve, miért ne?? hiszen a zip, meg divx kedvéért hoztak létre speciális utasításokat is a procikba.
Akkor leszarom az sse utasításokat és neki állok a bitléptetõ operátorokkal szórakozni, szar lassú lesz, de remélem ki tudom dumálni hogy miért, és meg tudom magyarázni,hogy ennél lehet 10 szer gyorsabb is, hardveres gyorsítással meg gondolom 100 szor is.

Egyet értek az elõttem hozzászólókkal. Szerintem is kamu.
Az nem érv, hogy túl lassú a C-ben írt kód. És azzal sem értek egyet, hogy akár a kész programnak képesnek kell lennie real-time kicsomagolásra.

Ha 3 hónap alatt tömörít be fél percnyi tetszõleges HD anyagot kb száz kByteba (ha 180 perc 20-30MB akkor fél perc kb 80kByte), akkor is kész lennél, hiszen mint mondtad az algoritmus az ötlet lényege, és nem a kód.
De nem. Te inkább SSE leírásokra vadászol, mikor még azt sem tudod mûködik-e a valóságban, amit kitaláltál, és fõként NEM TUDSZ FELMUTATNI ÍGY SEMMIT.

Vásárlót akarsz? A nagy szoftvercégek, és videós oldalak pontosan ugyanannyit fizetnének a tetûlassú változatért, mint a villámgyors SSE-t használó ASM kódért, hiszen õkat csak 2 dolog érdekli.
1. Lássák, hogy nem kamu.
2. A licenc jog.

Az optimalizálást õk is meg tudják csinálni ha kell.

Itt van egy kis leírás, hogy mások is értsék a dolog lényegét:
A cantor halmaz
Nem én találom ki ezeket a dolgokat, én csak erre írok egy algoritmust.

Hmm.
Nem tudom mi bajod van az entrópia fogalmával, a huffman kódolás is entrópia kódolás.
Pedig létezik az egységesített eljárás.
Érdekes, én meg mindenhonnan ezt hallom a suliban,hogy egységesített, egységesített, és az UML a leíró nyelve. Ez egy grafikus ábrázolás, egységes,hogy mindenki aki részt vesz vagy késõbb kapcsolódik a fejlesztésbe könnyen áttláthatja.
SF.NET en is ezzel dolgoznak sokan a dokumentálást is ezzel végzik.
Lényegtelen.
Nem azt mondtam hogy a mandelbrot halmazból vettem az 5letet, hanem egy a mandelbrothoz közel álló felfedezésbõl, amihez köze van a kantor halmaznak is.
Igen, egy dimenziós számsorban érvényes a kantor por, talán a bitek, egyesei és nullái nem egy egydimenziós sorozatot alkotnak?
Igenis, a világunk hemzseg a paradoxonoktól.
Vannak ellentmondásos események, kimenetelek, mint mondjuki a kvantummechanikai kétréses kísérlet eredményei, amit a mai napig nem oldottak meg, ez a kísérlet aszerint változtatja eredményeit, hogy te a megfigyelõ vonatkoztatásban figyeled.
Akkor ott van a shrödinger macskája elméleti paradoxon. A matematikában ott volt a pozitron matematikai leírásában, amikor még fel sem fedezték és többen hülyeségnek mondták mert ez így lehetetlennek tünt, aztán mégis.
Ezzel csak azt akarom mondani,hogy a világ amiben élünk teli van olyan dolgokkal amik elméletileg, matematikailag nem lenne lehetséges, de attól még úgy mennek a dolgok ahogy mennek.

Kösz a referenciákat, áttanulmányozom vizsgák után.
Én csak annyit mondok,hogy nem kell hinni nekem, meg ez amúgy sem egy komoly eredmény, a tömörítéstõl nem oldódik meg a gáz ára, vagy nem lesz kevesebb éhezés a világban.Szimplán ha elkészül szebb lesz a video a nappaliban.
Majd ha elkészülök aki akar az ott lehet mert úgy is be akarom majd mutatni, talán az egyik egyetemen a nyilvánosságnak. Azért én is érzem hogy pár dolgot megváltoztatna az informatikában.
Azért mertem ide írni errõl a forumba mert már biztos vagyok benne hogy mûködik, hogy ne legyen az, hogy nagyot mondok és aztán meg sehól semmi, aztán meg jól beégek. Pedig írtam már elég sokat ebbe a forumba. Páran már ismernek,hogy nem csinálok segget a számból.
Programozásban sajnos nem vagyok olyan jó mint amilyen szeretnék, volt hogy vizsgán sem mentem át ezekbõl elsõre. De azért lassan haladok, max sokat fogok debugolni.

Teny, hogy osszehordott egy-ket dolgot a srac, de en azert nem huznek le senkit csupan feltetelezesekbol kiindulva majd tenykent kezelve. Lattam en mar kep es 3D mozgasfelismerot is olyan manustol aki anno ~10 evvel ezelott a "hello world"-ot hetekig nem tudta megerteni valamint nagysagrendekkel tobb zoldseget hordott ossze.

Most a kinai kormany vendegszeretetet elvezi es egy ottani egyetemen tanitja a talalmanyat eleg szep jovedelem mellett. <#ravasz1>

LOL :D Frayer, percekig sírva röhögtem...

Csak néhány apróság:
- tanuld meg az entrópia definícióját, és akkor nem fogsz ellentmondásos dolgokat írni (és gondolni) róla
- idén végzek infó szakon, de esküszöm soha nem hallottam még "Száraz teszt logikai emuláció"-ról, ami "az implementáció és az analízis között" lenne, kérlek mutass linket egy erról szóló leírásra, nagyon érdekel mi ez
- miféle "egységesített szoftverfejlesztési eljárás"? van egy csomó szoftverfejlesztési paradigma, mindegyik másra jó, nincs egységesített. írd le melyikre gondoltál
- a procik utasításkészleteirõl rengeteg infó van
- a Mandelbrot halmazok _nem_ véletlenszerû struktúrák, hiszen egy jóldefiniált függvény írja le õket
- a világunkat nem paradoxonok írják le, ez simán faszság. paradoxonok azért léteznek, mert a világ leírásához használt modellek nem tökéletesek, továbbá a létezésükbõl nem következik hogy a te programod jó lesz. tanulnod kéne logikát is
- Einstein ikerparadoxona a fizika (konkrétan az idõ) paradoxona, köze nincs az információelmélethez
- a Cantor-halmazokat folytonos, egydimenziós térben értelmezzük, és inkább analitikai érdekességnek számít. nem is értem hogy sikerült ezt összehozni a tömörítési eljárásokkal
- szeretném látni azt a levezetést ami a Cantor halmazokat használja fel egy zajos csatornán a bithibaarány megállapítására
- az asszociatív tömbök egyetlen hardveres megvalósításáról tudok, ez pedig a prociban lévõ TLB (Translation Lookaside Buffer), és nem lehet programozni. a szoftveres asszociatív tömbök meg közismerten piszok lassúak, ezen kb elvérzett az egyik hozzászólásod
- olyan "gcc plugin" ami csinál neked saját programnyelvet nincs és nem is lesz soha
- "tesztek" (elágazások) nélkül nem lehet olyan programot írni ami csinál is valamit
- news flash: a c++ kódba lehet asm betéteket tenni (igen, sse utasításokat is)

természetesen ha bármikor (legyen mondjuk 10 éven belül) demózol nekem egy a lenti feltételeknek megfelelõ _mûködõ_ be- ÉS kicsomagoló programot aminek én adhatom a bemenetét akkor leborulok elõtted, de van egy olyan érzésem hogy erre nem lesz szükség :)

ja, még valami: majd figyelj arra hogy a programod kicsomagoljon egy HD képet 40msec-onként (általad választott processzoron), mert ha ennél lassabb, akkor a 24fps nem fog menni :)

Azért jól szórakoztam. És minden elismerésem: élénk a fantáziád, ami egy fontos dolog, de azért ne csinálj magadból hülyét :)

Poénból rákerestem, AMD fõoldaláról három kattintással le lehet szedni a keresett doksikat. Belinkelem ide, ezzel is támogatva az "erõfeszítéseid":
AMD Software Optimization Guide

Ajánlom a 9. fejezetet (szép példák is vannak asm-ben, hogy ne érje szó a házat...)