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 ;)
"É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.
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.
@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...)
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
É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.
" 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ó.
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.
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...)
Hat szereny velemenyem szerint Te kamuzol, (vagy csak szimplan idiota vagy, mar ne is haragudj) de ha telleg csak a az SSE-n mulna a dolog, hat tessek: http://softpixel.com/~cwright/programming/simd/sse.php http://www.tommesani.com/Docs.html (aztan nehogy az legyen a kifogas, hogy angolul van, egyebkent google rogton kikopte)
Amugy dez-nek igaza van, meg barki, aki kicsit is jartas a programozasban, azonnal vagja, hogy egy fejlesztesnel az optimalizacio a legutolso lepes. Irdd meg az uber-algoritmusodat C++ -ban, tok mindegy, hogy milyen lassu lesz (amugy bitenkenti logikai operatork asm-ban sem lesznek gyorsabbak) aztan ha mukodik biztosan, akkor kezdd el optimalizalni. De megen fenntartom, hogy szvsz Te itt csak hulyited a T. torzskozonseget, vagy fogalmad sincs, hogy miket beszelsz, plane ilyen kijelentesek utan: "sima c++ meg egyéb nyelvekkel nem igen lehet proci szinten kavarni a bitekkel"
Megis mit gondolsz, a C++-ban irt kodot, (ami gepi kodra fordul), gonosz manok hajtjak vegre a processszor helyett? :)
Komolyan mondom el nem tudom képzelni, hogy valaki ennyire fontos, hatékony és komplex dolgot fejlesszen ki, ha képtelen megtalálni egy publikus referenciát az intel oldalán: Intel® 64 and IA-32 Architectures Software Developer's Manuals Van az oldalukon máshol is még jónéhány referenciakönyv, ha ez kevés lenne.
Személy szerint egyébként sem tudok komolyan venni valakit akinek ennyire pocsék a helyesírása...
Eloszor az jutott eszembe, amiket irtal, hogy a Bibiaban hihetobb dolgokat olvastam, de a magam parasztos elmeleti oldalarol megkozelitve az jutott eszembe, hogy hiszen pl a Mandelbrot halmaz is vegtelenul komplex, es vegul is egy nem tul bonyis algoritmus irja le! Vagy is ha egy kep abrazolasara talalunk nehany szaz "kozelito" fraktal fuggvenyt akkor akar kepkockankent/kulcskepkockankent par szaz byte-tal leirhatunk mindent.
Aztan meg az jutott eszembe, hogy nem igaz hogy ezt nem csinalta mar meg valaki!;)))
Ha én bármi hasonló volumenû dolgot fejelsztenék, akkor a lehetõ legtitkosabban tenném ezt...ugyanis ha "hihetõ" hogy valaki ilyet csinál az a "gonosz feketeöltönyös fickóknak" már tökmindegy hogy télleg meg tudja-e csinálni, vagy csak kitalálta.
"Én nem egy profi programozó csapat vagyok. Hobby szinten kezdtem el fejleszteni, programozást is még csak tanulom, igaz már évek óta, de még nem vagyok benne olyan jó."
Asszem ezt elolvasva egyre inkább azt képzelem, hogy csak kitalálod az egészet...
Ne legyen igazam...de ha télleg ilyesmit csinálsz akkor télleg szükséged lesz valamiféle védelemre, mert túl sok embernek nem áll érdekében az ilyesmi... De szerintem erre neked is gondolnod kellett volna...vagy még túl fiatal vagy...ha ez pedig így van akkor méginkább gyanús a dolog.
Mindenrõl a MS tehet arról is ha esik, ha fúj, ha villámlik, ha tûz van, ha hurrikán... stb SZÁNALMAS
Már több, mint 6 éve abbahagytam a programozást, úgyhogy érdemben hozzászólni ezekhez a hozzászólásokhoz nem tudok már
De legalább értem, mirõl van szó
Nem, te ezt írtad: "sima c++ meg egyéb nyelvekkel nem igen lehet proci szinten kavarni a bitekkel" Pedig lehet. Csak persze nem lesz a lehetõ leggyorsabb, de az elsõ cél, hogy mûködjön, egy ilyen teljesen új eljárás.
Ha tényleg mûködik a dolog, akkor teljesen felesleges itt az assemblerrel szenvedned. (bár szvsz többet érne ha az ebbe fektetett energiából inkább megtanulnál hatékony kódot írni C-ben) Megírod olyan sebességûre, amilyenre sikerül, felbérelsz néhány gorillát, hogy ne öljenek meg, felrakod egy laptopra a progit és bemutatod valami pénzes csókának. Ha tényleg mûködik, akkor úgyse érdekel senkit amit összegányolsz assemblerbe, részben mert megírják mások, részben meg mert úgyis célhardver készül rá azonnal.
Amúgy az az érzésem, pár év múlva nem leszel büszke erre a topikra...
Dzsilett, most mondom,hogy ezek a c++ operátorok lassúak, és nem optimalizáltak, gyakorlatilag 8086 os utasítások lesznek belõlle, gcc-vel leforgatva. De akkor már jó lenne ha lenne valami see kiterjesztett támogatás hozzá a gcc hez vagy valami más c++ compillerhez, nekem mindegy, csak kezelje a sztandard c++ és api hivás könyvtárakat.
Nekem jók lennének friss asm kódok, a legjobban egy teljes sse utasításkészlet referenciának örülnék, asm kódokkal. Mivelhogy assembly volt az elsõ programozási nyelv amiben tanultam, 10 éve. Leszámítva a basic-et c-64 en, amit én nem neveznék programozási nyelvnek, inkább scriptnek. Na mindegy, ha tudsz sse referenciát akkor linkeld már be, google erre nemjó, intel oldalain semmi. Ha publikusak, akkor honnan a faszból tudjam meg? Az intelnek is elvileg az lenne az érdeke hogy mindenki hozzáférhessen mivel így biztosított minél több programban az intel procik támogatása. Na jó amd is támogatja az sse-ket. C++ ban sokkal nehezebb megírni mint asm-ben, mert teljes egészében bitekkel dolgozik a kód, és hát c ben a bitléptetõ operátorokkal szórakozni, átkonvertálni, fejben kiszámolni hogy mikor milyen bitsorozatra milyen c++ kódot írjak az elég komplex és nagy lenne a hibalehetõség is. A c++ az jó, de csak ha beágyazott asm kódokkal írom meg a magját ami az adatokkal dolgozik, az egyébb funkciók meg c ben lesznek lekódolva.
2. Száraz teszt logikai emuláció, tudod, ami az egységesített sw fejlesztési eljárásban az implementáció és analízis között van.
a.m. operátorokat :) Ezek: & AND | OR (inkluzív) ^ XOR (exkluzív OR) <<(x) shift balra x bittel >>(x) shift jobbra x bittel ~ egyes komplemens (invertálás) (Nem keverendõk a logikai operátorokkal (&&, ||, stb.).) Érdekes, ha egy számtech tanár nem ismeri ezeket...
Mit értesz az alatt, hogy túl szakiknak szól? A vonatkozó asm utasítások leírása? Ha igazán optimális kódot akarsz, kénytelen leszel megismerkedni vele. Majd, egyszer... Most elõször írd meg sima C-ben! Itt a bitenkénti logikai operatárokat használhatod. Mûködjön, aztán lehet majd optimalizálni...
Én lossless 48khz 24 bites hangal számoltam HD video révén 30fps el 24 bites színmélységgel. De nem az a lényeg,hogy mekkora a kiinduló értékek mérete, hanem hogy milyen gyorsan tud dolgozni a processzor, mennyi idõbe telik az adatok helyreállítása a kezdeti állapotba. Negatív hatás : rekurzív az algoritmus, ezért többször át kell futni a kódon, egymás után akár több százszor is. Pozitív hatás: Az algoritmus soros szervezésû és nem vizsgálja meg a környezetében lévõ több ezer bájtot, minden egyes bit-szekvencián. Ezért egy iteráció gyorsaságát inkább csak a memória sávszél fogja korlátozni, fõleg ha meg tudom oldani hogy tesztelõ operátoroktól mentes legyen a kód.
Szoftveres emulációval jól ment eddig a dolog, de foggalmam sincs hogy pontosan milyen gyors lesz a kód egy valódi procin.
Linket tudnál adni? Mert az is teljesen nonszensz, hogy 2000-3000 megába beleférjen (legalább az 5szöröse kéne hozzá), de ez a 20-30 mega az ugyanmár kategória. Egy 32 bit színmélységû 1920*1080-as lossless kép kereken 8 mega. Kb 3 ilyen kép férne el az általad leírt 20-30 megában, ami 24fps-t nézve 1/8-ad másodpercet jelent, nem 180 percet. Ráadásul a hang bele sincs kalkulálva :)
Frayer: Vagy te vagy a megváltó, vagy csak hülyeségeket beszélsz. Én nem tudom eldönteni, mert egy szót sem értek abból amit írsz. De az biztos, hogy amíg nem lesz itt a kezünkben a mûködõképes codec, vagy annak egy feltört változata (tökmindegy), addig az átlag ember szemében te csak egy esgés fórumozó vagy, aki nagyokat mond. Az is kicsit vicces, hogy mindeközben a vizsgaidõszak miatt aggódsz. o.O
Mindenesetre drukkolok.
jameg elneveznéd az algoritmusodat (Food)LFG-nek, a nevem után ? thx
Hidd el haver kerestem. De vagy túl szakiknak szól, vagy õsrégi asm kódokba botlottam ami õsrégi utasítás készletet használ. Azt viszont tudom,hogy hardwareben otthonosan mozogsz, adhatnál nekem linkeket erre vonatkozólag. Ami érdekel, gyors mûveletek bitekkel, bitsorozat keresése, bitek állapotától függõ kódvégrehajtás, olyan ami gyorsan mûködik. Ha lehet minél kevesebb jmp,jnz meg egyébb tesztelõ elágazásokkal, azt tudom,hogy ezek sok proci idõt vesznek el mert a tesztelt eredménytõl függõ vizsgálat megbontja a soros pipelineokat. Erre azt találtam ki,hogy a sorban lévõ bitek értékét ha lehet egy egyszerû sse utasítással betöltöm egy 8 bites "al" regiszterbe és ezt a regisztert használom referenciának egy asszociatv tömbben ami a szükséges kódszekvenciára mutat, így megsporolva egy tesztelõ operátort mint a jnz, asm-ben. Amúgy talán még egy olyan plugin vagy valami is jól jönne amit be tudok építeni a gcc-be és általa sse készletre optimális kódokat tudok írni, sima c++ meg egyéb nyelvekkel nem igen lehet proci szinten kavarni a bitekkel, a short int, meg char-nél nem nagyon vannak kisebb típusok :(, mivan ha nekem épp 2 vagy 3, 4 bitet kell vizsgálnom, de szélsebesen??? Ilyenkor mi a teendõ? Tanár nem tudja, senki nem tudja :S azér ez már durva, okosabbak azt mondják, nézzek utánna a kiterjesztett utasításoknak amik bitekkel operálnak, de google nem sokat segít.
Nemreg olvastam egy cikket az XBOX torteneterol, es abban az volt hogy a jatekgep projekt gyak versenyzett egy letoltos videossal, es a jatekgep nyert. Nos azota a Micro jo par milliardot vesztett ezen az uzleten, ahogy azt valamelyik alkoto meg is mondta, majd kilepett projrktbol. A letoltos video meg azota valaszeg befutott volna. Szal az hogy a Mikrobi ebben a temakorben mozog nem ujkeletu.
"nincs sok infó a procik kiterjesztett utasítás készleteirõl, ehez meg kellene mert elég speciális bitekkel dolgozó kódja van. Amit találtam az régi ASM kódok mmx re meg kibõvített pentiumra. De az lófasz az ss4 korában."
Viccelsz??? Teljesen publikus a dolog. Talán kezdd a világmegváltást a google megismerésével... ;)
Ez a fraktálos ötlet nem új. Pl. én is elkezdtem írni egy ilyen tömörítõt úgy 16 évvel ezelõtt (szilveszterkor bulizás helyett, mert izgatott a dolog :P). De túl lassú lett volna. Legalábbis akkor.
"és ezt annyiszor játszod el ahányszor csak akarod és mindig kisebb lesz az eredmény"
Nem, egy idõ után természetesen a kapott számhalmaz már nem kisebb, hanem nagyobb.
Nemtom, én nem az a gyerek vagyok abból a topikból.
1, 1 bitbe az én megoldásommal nem lehetne, a tömörített adat tartalmazza a rekurzió számlálót, több stream szekvenciát is el kell határolni egymástól és azoknak is le kell írni az állapotait, meg hogy hól kezdõdik és hól van vége, stb. Egy bitbe nem, de egy két százba már be lehet tömöríteni. Pontosan nem tudom milyen sebességgel, de ahogy elõzetesen számolom, kb másodpercenként úgy 50-80 megabájtot be tudna csomagolni, egy 1 ghz-s procival 2,7 Gb/s es memória sávszélen. Ha sikerülne megoldanom a bitekkel dolgozó sse utasításokkal való munkát, csak 8086-os bitléptetõ utasításokkal 10X lassabb a dolog.
2. Azon vagyok, de elõbb hagy készüljön már el. 3. Egyértelmû hogy e nélkül semmit sem érne :D
Biztos tök véletlenül állt a Paramount a HD_DVD mellé (elõzõleg elvbõl mindkettõt támogatta...), amikor már éppen nyerni készült a Blu-ray... Többszörös eladások, stb. Most meg megint közel patthelyzet... Így az emberek többsége továbbra is kivár, nem vásárol. Biztos ez a jó a kiadóknak is...
Nem szerzek komoly vasarlot, amig nem latom a kesz termeket. Amugy meg nehogymar kulfoldi kezbe keruljon egy ekkora ertek. Eloszor add el nekem, aztan ha jo, akkor add el a Google-nak, ok?
ui: az a topic több mint két éve kezdõdõtt a nagy bizonygatások ellenére a mai napig nem létezik ez az eljárás, ahogy a tiéd sem fog sohasem. Remélem nem joysoft vagy vagy derx csak épp más néven...
Informatika és tudomány
