Názory k článku
Programujeme JPEG: Interní struktura souborů typu JFIF/JPEG

Co koukam do nejakeho realneho PDF souboru, tak ma v sobe vlozeny cely JFIF i s hlavickou, takze to mozna nebude idealni priklad. Dalsi problem je, ze diky rozsireni digitalnich fotaku se dneska v souboru s priponou .jpg casto ukryva pro zmenu Exif...

Zalezi na tvorbe PDF, muze tam take byt pouze bytestream bez hlavicky. S temi EXIF mate pravdu, misto hlavicky APP0 tam byva APP1 (hexa kod je o jednicku nebo dvojku vetsi), ktera jeste obsahuje EXIF informace, popr. take FlashPix.

Nejzajimavejsi vsak jsou "Microsoft JPEGy", ktere se vytvori tak, ze se k obrazku pridaji informace o autorovi, nazvu atd. (pres dialog Exploreru) Tyto informace se v JPEGu "rozprostrou" mezi ostatni segmenty, ale jeste jsem presne nevyzkoumal jakym zpusobem. Nicmene ctecky s tim problemy nemaji, kazdy segment ma svoji delku a zbytek se - az do dalsi znacky - ignoruje.

Mimochodem, ty "díry" mezi segmenty (nebo v APP1 za EXIF) jsou také v souborech z některých foťáků. Jejich význam mi však zůstal utajen, nejspíš jde o zaokrouhlení, čemuž odpovídá i fakt, že DQT začíná vždy na adrese ??????b5.

Na konci souboru bývá ještě druhý náhled (první, menší, je v EXIF).

Bylo by zajímavé upozornit na stařičký program jpegdump, který umí právě tuto strukturu souboru JFIF popsat.

Foto je z Minolta A1:
jpegdump pict1903.jpg
pict1903.jpg:
offset $0 SOI
offset $2 APP1 (length 32689)
Exif\000\000MM\000*... vynecháno ...
offset $7fb5 DQT (length 132)
table 0 precision 8
Approximate quality factor for qtable 0: 95 (scale 10.71, var 62.00)
table 1 precision 8
Approximate quality factor for qtable 1: 95 (scale 10.16, var 47.37)
offset $803b DHT (length 418)
table 0
table 16
table 1
table 17
offset $81df SOF0 (baseline DCT Huffman) (length 17)
sample precision 8
width 2560, height 1920 components 3
id 1 horizontal sampling 2, vertical sampling 1, quantization table 0
id 2 horizontal sampling 1, vertical sampling 1, quantization table 1
id 3 horizontal sampling 1, vertical sampling 1, quantization table 1
offset $81f2 SOS (length 12)
components 3
id 1 dc table 0, ac table 0
id 2 dc table 1, ac table 1
id 3 dc table 1, ac table 1
spectral selection 0 to 63, bit position high 0, low 0
offset $24414a EOI
offset $2441b5 DQT (length 132)
table 0 precision 8
Approximate quality factor for qtable 0: 49 (scale 103.03, var 4566.28)
table 1 precision 8
Approximate quality factor for qtable 1: 51 (scale 97.74, var 3910.68)
offset $24423b DHT (length 418)
table 0
table 16
table 1
table 17
offset $2443df SOF0 (baseline DCT Huffman) (length 17)
sample precision 8
width 640, height 480 components 3
id 1 horizontal sampling 2, vertical sampling 1, quantization table 0
id 2 horizontal sampling 1, vertical sampling 1, quantization table 1
id 3 horizontal sampling 1, vertical sampling 1, quantization table 1
offset $2443f2 SOS (length 12)
components 3
id 1 dc table 0, ac table 0
id 2 dc table 1, ac table 1
id 3 dc table 1, ac table 1
spectral selection 0 to 63, bit position high 0, low 0
offset $24d6ad EOI

No, mě hlavně zaujalo, jak Microsoft ty své údaje do JPEGu vkládá, protože EXIF je celkem jasný. Například jsem nastavil vlastníka na "Pavel", ale místo toho se v souborech objevila záhadná sekvence znaků trošku připomínající rozsypané a ořezané ASCII, například "%&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz". Ale kdo chce kam..., já většinou tyto informace z JPEGu vyhazuji, abych byl co nejvíce "kompatibilní".

Ale jpegdump je opravdu použitelný, vypisuje i nestandardní věci. Já v příští části ukážu své dva prográmky, ty umí vypsat obsah hlavičky, DQT a DHT. Třeba to někomu při zkoumání vnitřností JPEGu pomůže, minimálně z tvaru DQT může v některých případech zpětně odvodit, který program JPEG vytvářel i bez EXIF :-)

Ten začátek DQT je zajímavý, určitě to v žádné normě takto omezeno není, snad že se ve všech foťácích používá stejný enkodér :-) [stejné chyby, stejné známky...]

Já jsem měl na mysli začátek DQT pro všechny fotky z mé Minolty. Fotky z jiných foťáků jsem nijak nezkoumal.

Pro zajimavost jsem se podival na JPEGy vytvarene nekterymi fotaky a je to docela zajimave. Napriklad Nikon Coolpix (tusim ze 8900) nevytvari segment APP0, ale ma jenom EXIF hlavicku. Naproti tomu Olympus µ ma jak APP0, tak i EXIF. Zavislost mezi zacatky jednotlivych segmentu jsem nevysledoval, takze Minolty asi budou mit jiny firmware (ted me napadlo, ze porovnanim zpusobu tvorby JPEGu by se dalo vysledovat, jestli nejaky vyrobce firmware neobslehl :-).

Nebo nelicencoval. To ovšem může zkomplikovat OS a platforma. Zde najdeme značné rozdíly - od klonů MS-DOSu až po realtimový pSOS.

Podle svých pokusů jsem došel k závěru, že Minolta asi nepoužívá standardní knihovnu jpeg - pomocí jpeg knihovny nejsem schopen obrázek překomprimovat tak, abych dosáhl stejný výsledek (rozdíl mezi původním a překomprimovaným výsledkem je vždy nenulový, a to nejen u okraje obrázku).

Tak to tedy nevim, setkal jsem se hlavne s ASCII. Ale mozna bych zkusil UTF-8. Vite co, zkuste mi poslat nejaky "zmrseny" komentar, ja to projedu konvertorem a pokusim se to kodovani zjistit.