JPEG validator pythonban VS. truecolor terminal :)

Adódott egy probléma, kb 100 ezer jpg filét kellett volna ellenőrizni nem sérültek-e, anélkül hogy végignézném. A legtöbb képnéző / konvertáló / libjpeg viszont elég jól viseli a hibákat, és nem is nagyon lehet automatizáltan lekérdezni a kisebb sérüléseket, inkább kijavítják / átugorják. Elkezdtem hát írni egy jpg file parsert, már nem tudom miért, de pythonban ( ezt később megbántam )

Eleinte egyszerűnek tűnt, de minél jobban beleástam magam a jpeg specifikációkba és implementaciokba, úgy jöttek elő a trükközések, bugos implementációk stb. és kezdett eldurvulni a kód. A másik, hogy megpróbáltam sebességre optimalizálni ( pythont, jah... ) és sikerült is kb a duplájára gyorsítani a bitműveletek átírásával, végül python 3.8-al olyan 300kB/sec-el megy a huffman-dekoder, pypy-vel még 10x gyorsabban. De 1-1 nagyobb ( 10-20 megás ) filenál így is érezhetően elgondolkozik, hát tegyünk bele valamilyen progressbart. meg aztán azt se ártana tudni, egyáltalán működik-e a dekóder, addig oké hogy végigmegy a bitstreamen, de ki tudja hogy a dekódolt számhalmaz jó-e valamire.

Első gondolatom: ASCII art :) mekkora poén volt 20 éve mplayerrel konzolon videót nézni... heggesztettem is bele egy rögtönzött ascii art megjelenítőt, ami néha meglepően jó eredményt adott:

http://thot.banki.hu/arpi/jpeg/ascii.png

Aztán eszembe jutott, hogy valahol láttam már egész színes terminál kiírást is... némi google hozott is egy tucat találatot, ez talán a legérdekesebb közülük:

https://github.com/Textualize/rich

Végül nem ezt használtam, de az ötlet jó. Ha modern terminálunk van, valószínűleg támogat truecolor megjelenítést:

COLORTERM=truecolor
TERM=xterm-color

és akkor az alábbi ESC kóddal lehet R-G-B színre beállítani a foreground ( 38 ) vagy background ( 48 ) színét: b[38;2;R;G;Bm

Na kombináljuk ezt össze a jpeg parserrel, mégpedig úgy, hogy 1 karakter helyen rögtön 2 pixelt is megjelenítek, mégpedig úgy, hogy az unicode lower half block karaktert használom, a háttér és az előtér színét pedig a 2 pixel színére állítom be, és máris színesbe jön a jpeg a konzolon:

http://thot.banki.hu/arpi/jpeg/color.png

ha valakit nagyon érdekel a kód, íme, de még erős idegzetűeknek sem ajánlom, annyira gány : ) ) )

http://thot.banki.hu/arpi/jpeg/testjpeg.py

( Hiena v | 2022. 07. 10., v – 07:21 )

Nice.

"megpedig ugy hogy az unicode lower half block karaktert hasznalom, a hatter es az eloter szinet pedig a 2 pixel szinere allitom be, "

ZX Spectrum valaki? Ott lehetett ilyen búvészkedésekkel javítani a képminőségen.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( harlequin | 2022. 07. 10., v – 09:07 )

ha már Python: a PIL verifyje nem pont erre van? (gyakorlatban nem használtam, de párszor már szembejött)

“Any book worth banning is a book worth reading.”

nem ismertem, de a docs szerint nem tud tobbet mint az en elso, kb 20 soros validator kodom:

Image.verify()[source]

Verifies the contents of a file. For data read from a file, this method attempts to determine if the file is broken, without actually decoding the image data.

De azert kiprobaltam most egy total szar fileon, es azt is valid-nak mondta... de ha jol latom a PIL forrasaban, a jpeg image plugin meg csak nem is implemetalja a verify()-t az intarface-bol...

( trey | 2022. 07. 10., v – 11:14 )

Szerkesztve: 2022. 07. 10., v – 11:15

Rá lehetett volna engedni az ékezetesítőt erre a postra:)

trey @ gépház

( egmont | 2022. 07. 10., v – 11:48 )

Szerkesztve: 2022. 07. 10., v – 11:53

A \e[38;2;R;G;Bm nem hivatalos, nem szabványos, bár a legtöbb helyen működik (valszeg több helyen, mint a hivatalos). A hivatalos a \e[38:2::R:G:Bm (kettőspont, és eggyel több belőle, mert ott van valami (nem használt) color space paraméter az ITU-T T.416 §13.1.8 szerint).

A felső/alsó fél blokk Unicode karakterekkel képrajzolás ötlete nem új, én is leimplementáltam amikor a gnome-terminálba (vte-be) belehegesztettem a truecolor támogatást:

https://gitlab.gnome.org/GNOME/vte/-/blob/0.68.0/perf/img.sh

és amúgy én is loptam az ötletet már nem is emlékszem hogy honnan, talán QR-kód kiíró progiból.

Jpeg dekódolást én nem csinálok, ahhoz nem értek, csak a bitmapet átültetem a terminál nyelvére.

Nem árt hozzá egy olyan terminál (pl. gnome-terminal/vte), amelyik kézzel rajzolja ezeket a glyph-eket, mert a fontból szedve nem tökéletes általában, marad alul-felül-oldalt csík.

Én a felső blokk karaktert használom, mert ha páratlan pixelsorból áll a kép, akkor fölfelé szeretném igazítani, és így tudok alul egy pixelsornyit (fél terminálsornyit) kihagyni hogy ott a terminál háttere látszódjon.

Jó látni hogy nemcsak én kattantam rá a témára :)

mint ezt mar feljebb is kitargyaltuk, ezt a fel karakteres hatter/betuszin allitgatast mar 30 eve is csinaltak 8 bites gepeken, annyira nem ujdonsag... eleg nehez lenne megmondani ki talalta ki eloszor...

nekem is csak a rgb truecolor szin allitasi lehetoseg volt ujdonsag, terminalon eddig en csak a 16 szines palettat ismertem.

Tapasztalatom szerint nem igazán, vagy legalábbis csak ennél sokkal-sokkal nagyobb ötletek esetén.

Amúgy a truecolor támogatás tracker bugjában belinkeltem a képnézegető ötletét (https://bugzilla.gnome.org/show_bug.cgi?id=704449#c5), tehát neki megadtam a kreditet, még ha nem is közvetlenül a forrásban. Bár az a képnézegető minden pixelből 1 egész cellát csinál. Ezt tehát még kombinálni kellett egy másik ötlettel, a függőlegesen felére összenyomással. Ez az amit talán láttam már akkor terminál-alapú QR-kód generálóban, de lehet hogy nem, mindenesetre a szóban forgó Unicode karaktereket és a VTE kézzel rajzolását már ismertem akkor (ezt https://bugzilla.gnome.org/show_bug.cgi?id=709556 bizonyítja), szóval ez a lehetőség szinte biztosan eszembe jutott volna akkor is, ha a félblokkokat használó QR-kód generálót nem látom korábban. De valószínűleg a képnézegető ötlete is előbb-utóbb eszembe jutott volna, ha nem látok ilyet korábban.

Ha a kreditet minden ilyesmi esetben legalább illene, neadjisten kötelező volna dokumentálni, az gyakorlatilag lehetetlenné tenne bármiféle fejlesztést (de akár műalkotás készítést, stb), hiszen a munka igencsak nagy része az hogy kismillió korábban már látott mintát szedsz elő és rakod össze a számodra szükséges konstrukcióban. A fejemben lévő tudás és tapasztalat igencsak elenyésző részéhez van meg az a metainformációm, hogy az honnan származik, és azt hiszem, ez így van jól.

( Raynes v | 2022. 07. 10., v – 21:12 )

Badass projektjeid vannak, meg kell hagyni. Bár ezzel most lehet feleslegesen futottál kört, mert vannak erre kész megoldások. Jpeg ellenőrzésére a jpeginfo, illetve terminálban képek megjelenítésére meg xterm-ben a sixel, más terminálokban az uberzug. Sose használtam még ezeket, mivel szerintem a terminálnak nem feladata képek megjelenítése. Kihekkelhető, de nem arra használjuk, amire való. Főleg, hogy úgyis csak X vagy Wayland alatt van értelme, hogy meglegyen hozzá a szükséges színmélység és felbontás, de ha az már megvan, akkor miért ne jelenítsük meg grafikus appal, pl. imv, sxiv, nsixv, xv, stb., ez utóbbiak is minimalista programok.

Ha már ennyire intenzíven nekiálltál az utóbbi időben programozni, akkor lenne nekem egy projektötletem, amit én akartam megírni, de lusta vagyok hozzá: kernelmodul, ami a PC speakerre való adatokat nem a PC speaker hardverre küldi, hanem ALSA-n keresztül a rendes hangchip kimenetére, de úgy, hogy szabályozni lehessen a hullámformáját is, azaz ne csak négyszöghullám legyen, mint PC speakernél, hanem mondjuk szinusz vagy hasonló, hogy ne legyen olyan élesen csipogó, idegesítő hangja. Szerintem hasznos lenne, és nem próbálkozott még senki ilyennel. Persze ha van kedved ilyesmihez.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

> lehet feleslegesen futottál kört

valoszinu, de erdekes volt elmerulni a jpeg formatum bugyraiban...

> Jpeg ellenőrzésére a jpeginfo

ugy latom ez libjpeg6-ot hasznal, azt probaltam mar es megeszi a kicsit hibas fileokat...  a jpeg formatumot eleve ugy terveztek, hogy hibaturo legyen, kisebb hibakat a dekoder tud kezelni, atugrani, megkerulni, igy a kep kicsit hibas lesz de nagyjabol meglesz. ezert van telerakva markerekkel, hogy hiba esteen a kovetkezo markertol tudja folytatni. nekem viszont pont az volt most az erdekes, hogy az ilyen fileokat kiszurjem, ami latszolag jo, de megse tokeletes.

> terminálban képek megjelenítésére

ez egyaltalan nem volt igeny, csak fun factor benne, hogy megis lassam kb hol tart mit csinal. sima progress barnak indult, csak aztan ugy voltam vele, akar a kepet is megjelenithetem soronkent, abbol is latszik hogy halad vele.

> nekiálltál az utóbbi időben programozni

nem tudok rola, hogy az elmult 30 evben abbahagytam volna :)  max nem publikaltam ide...

> Persze ha van kedved ilyesmihez

ezt a kernel driveresdit kihagynam, koszi. 20 eve meg irogattam drivereket, akkor sem volt egy elmeny. ma mar akkor se, ha fizetnek erte...  amugy emlekeim szerint ugy az intel a 815 chipset ota hardverbol tud ilyet hogy az ac97-re kuldi a speaker hangot, szoval ertelmet se nagyon latom ennek.

Ja, jó, te tudod. Csak egy ötlet volt akkor, hangosan gondolkodtam. Azt nem tudom modern gépek hogy csinálják a PC speakert, de mindegyiken ugyanúgy fülmetszően élesen szól, mint anno a régi PC-k speakerén is. Ennek ellenére lehet, hogy már hangchipen keresztül küldi, de még mindig négyszöghullámként, azért szól ugyanolyan idegesítően.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

A jpeg-ges kérdéskörhöz: attól, mert libjpeg6-ot használ, az nem azt jelenti, hogy azzal is ellenőrzi a jpeg-et. Attól lehet valami saját algoritmusa is. Van -c kapcsolója.

Bár még mindig tartom, hogy ezt nem így kéne ellenőrizni. Erre általános checksum megoldások valók, amik nem csak jpeg-re jók, hanem mindenféle adat konzisztenciájának az ellenőrzésére, pl. ZFS-es tárolás, RAID, stb..

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

> Attól lehet valami saját algoritmusa is.

de nincs:   ez csak egy wrapper a libjpeg6-ra...

https://github.com/tjko/jpeginfo/blob/master/jpeginfo.c#L360

> Erre általános checksum megoldások valók

aminek elofeltetele, hogy az osszes fileodrol legyen checksumod. de nekem csak ez a 100k .jpg file van mindenfele checksum nelkul (az is messze egy szerveren, amire csak ssh-m van), es meg kell valahogy mondjam, hogy hany %-a hibatlan...  (egy archivum adatmentesenek eredmenye)

( khiraly | 2022. 07. 11., h – 08:13 )

> ASCII art :) mekkora poén volt 20 éve mplayerrel konzolon videót nézni...

 

telnet towel.blinkenlights.nl 23

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( bennyh | 2022. 07. 11., h – 08:48 )

Engem is érdekelne tömeges validator, vannak ősi meghajtóim, jó lenne előszűrni, mit érdemes egyáltalán megtartani róluk és átmenteni.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

amire eddig megirtam kulonbozo okokbol:

- OLE2 (regi msoffice doc/xls/ppt de mas is hasznalja) - oletools strict modban megnyitva vegig olvasva a streameket, + xls parser

- ZIP  (beleertve az uj moffice docx/xlsx fileokat), ebben az xml-ekre kulon lefut egy xml validacio, plusz zip crc es zlib unpack

- PSD (az RLE-tomoritett kepet kibontja es ellenorzi a pixelek/byteok szamat, de a tobbit (layer infok, fontok stb) csak nagyjabol)

- PNG (van minden chunk-ra crc ellenorzes, plusz ki is tomoritem a zlib-es reszt, ellenorzom a compr/uncompr hosszt is)

- PDF (korabban irtam heurisztikus viruskereseshez egy eleg komplex pdf elemzot/parsert, az lett kibovitve hibaellenorzessel)

- JPG - ugye itt allunk most :)

a validacio (hiba ellenorzes) egyaltalan nem egyszeru, par kivetellel (zip, png) max a formatum specifikacionak megfeleles szigoru ellenorzeset lehet megcsinalni, de az egyreszt nem garancia a hibatlan filera, masreszt sok elvileg hibatlan file is megbukik rajta, a bugos implementaciok (letrehozo programok) miatt. pl pdf-nel ez nagyon latvanyos...

amiben van tomoritett data (pl. jpg, psd) ott meg az is egy plusz ellenorzesi lehetoseg, a kitomorites egyreszt hibara futhat, masreszt ellenorizheto, hogy a kitomorites vegen kapott adat mennyisege megfelel-e pontosan az elvartnak (pl. kep meret alapjan w*h*ch*bits), se tobb se kevesebb nem lehet. ez azert erdekes, mert pl. egy jpeg file kozepebe belekerult 00 byteok (mondjuk 1 hibas szektor) eseten is nagy valoszinuseggel dekodolhato (a leggyakoribb huffman kodok 0 bitekbol allnak), de a vegere erve vagy tobb vagy kevesebb MCU blokk lesz, mint a kep merete alapjan szukseges.

lehet, bar jpegnel nem talalkoztam ilyennel.  van mondjuk 2 olyan fileom, amit a photoshop nem nyit meg (kiirja hogy corrupt) es az en parserem is hibasnak jeloli (hianyzik 1-2 MCU), de amugy barmilyen kepnezovel vagy kepkonvertaloval "jo". gyakoratilag az utolso 1-2 pixele hibas csak, es csak full belezoomolva latszik, de akkor is csak ha nem feher pixelt rak a hianyzo helyere az adott dekoder. de ezek valamilyen scannelt kepek, nem tudom, hogy a scannerbol jott igy ki vagy valamivel szerkesztettek es az rontotta el.

a fenykepezokbol kihanyt jpg-kkel mas "problema" szokott lenni: a full size jpg vegere odabiggyesztenek egy kisebb meretu preview jpg kepet is (nem thumbnail, az is van de az be van agyazva az EXIF-be, es annak technikai okokbol 32kB a max merete). az tipus fuggo, hogy hogyan, japan gepek foleg az amugy nem tul elterjedt MPext extensionnel oldjak meg, de van ami csak siman hozzafuzi a vegere, es van ahol elobb van egy kb 20 byteos random valami (szerintem valami digit alairas lehet) es utana jon a preview kep. ezek a kepek filemeretben altalaban 10%-a az eredetinek, egy 10 megas jpg eseten kb 9mb az eredeti kep es 1mb a vegen a preview kep.

egyebkent a "kikukazna" eros, egyelore csak logolom, es azokat le kell kezzel ellenorizni, megnezni pl kepnezoben. eddig ugy kb 30 hibas jpg-t talaltam, ezek kb fele nagyon fos (p. a file fele hianyzik), de volt olyan is amin szemmel alig eszreveheto hibak voltak csak...

( arpi_esp v | 2022. 07. 16., szo – 22:15 )

Szerkesztve: 2022. 07. 16., szo – 23:05

elkezdtem validálni a validátort:  ugyanabban a közepes méretű jpg fileban random pozíciókon kicserél mindig csak 1 byteot, és megnézi lefut-e hibatlanu az ellenőrzés. hát...

00 byte:  8277/10027  (82.5%)
FF byte:  7928/10573  (75%)
random:  8141/10212  (80%)

arra számítottam, hogy ritkán, de előfordulhat olyan eset, hogy hibátlanul lefut a dekóder, mert a huffman kódban kicserélsz pár bitet, jó eséllyel másik érvényes huffman kódot kapsz (ez az entropy coding lényege, hogy minden bitkombinációt kihasznál), de arra már kicsi az esély, hogy a másik kód hossza is ugyannyi, ha pedig nem akkor onnantól borul a dominó és előbb utóbb hibára fut.

ehhez képest mint látható az esetek kb 80%-ban lefut hibátlanul :(  és ami (nem annyira) meglepő, hogy vizuálisan se látszik sok esetben a hiba a képen.

persze a gyakorlatban elég ritka az, hogy csak 1 byte sérül a fileban, minimum egy 512 byteos szektor szokott felülíródni/eltévedni...

16 random byte eseten is meg kb a fele atmegy a teszten:  6188/11321, es meg 2803 majdnem jo (par bit hijjan). 55% !

32 random byte eseten is jobb picit, 4552/10388, azaz 44%

128 random byte: 1643/10592  15.5%

nem. inkabb kiegeszitik egymast.

testdisk: tok jo particiok megkeresesehez, particios tabla javitasahoz, de ez ennyit tud.

photorec: ez - ahogy a neve is sugallja - arra jo, hogy fenykepezobol kiszedett cf/sd kartyarol visszahozza a torolt fotokat.

ugyan a progi mar sokfele file formatumot felismer, nehanyat egesz jol, de a gyakorlatban ha egy hdd-rol menteni kell akkor nincs sok haszna, mivel:

- a fragmentalodott fileokat nem tudja kezelni (hisz az az info hianyzik, a fat/mft/inode tablak tartalmazzak)

- a fileok eredeti neveit/datumat nem tudja helyreallitani, se a konyvtar strukturat, igy kapsz sokezer nevtelen filet omlesztve. ha a rendszer is azon a hdd-n volt, akkor meg a sok temp file is benne lesz, beleertve a bongeszo cache-ket (osszes weboldal kis-nagy kepei). ez igy a gyakorlatban teljesen hasznalhatatlan... nehany esetben azert van valami info (pl. ole2 formatumnal doc/xls stb), meg pdf-eket is probalja atnevezni a header alapjan, nem sok sikerrel, de pl. docx-eknel meg a datumot se szokta tudni, nemhogy a nevet. amugy pont erre is irtam egy toolt.

meg fejlesztes alatt van egy ami az INDX rekordokat keresi meg a disken, es az alapjan megprobalja rekonstrualni az eredeti konyvtarstrukturat es fileneveket, majd ezt a meret (es ahol van) datum alapjan osszeparositja a photorec filejaival. (az MFT-bol egyszerubb/jobb lenne, de sokszor az annyira serult, vagy formazas eseten ures, hogy anelkul kell megoldani)

a tobbi toolom raid5 es hibas ntfs strukturak (serult mft) javitasara/mentesere vannak, valamint a mentett fileok ellenorzesere, ilyet a testfisk/photorec tudtommal nem tud... sot mas se nagyon.