JPEG -filutbytesformat - JPEG File Interchange Format

Den JPEG File Interchange Format ( JFIF ) är ett bildfilformat standard. Den definierar kompletterande specifikationer för behållarformatet som innehåller bilddata kodade med JPEG -algoritmen . Basspecifikationerna för ett JPEG -behållarformat definieras i bilaga B till JPEG -standarden, känd som JPEG Interchange Format (JIF). JFIF bygger över JIF för att lösa några av JIF: s begränsningar, inklusive onödig komplexitet, komponentprovregistrering, upplösning, bildförhållande och färgutrymme . Eftersom JFIF är en kompletterande standard kan det resulterande filformatet kallas "JPEG/JFIF".

JFIF är ömsesidigt inkompatibelt med det nyare utbytbara bildfilformatet (Exif).

Ändamål

JFIF definierar ett antal detaljer som lämnas ospecificerade av JPEG del 1-standarden ( ISO / IEC 10918-1, ITU-T rekommendation T.81.)

Komponentprovregistrering

JPEG tillåter att flera komponenter (t.ex. Y, Cb och Cr ) har olika upplösningar, men det definierar inte hur de olika samplingsmatriserna ska justeras. JFIF-standarden kräver att samplingarna placeras " interstitiellt "-vilket betyder att avkodaren kan behandla varje komponentmatris som att representera en uppsättning av lika stora rektangulära pixlar som samplas i deras centrum, där varje grupp har samma yttre gränser som bilden. Detta är bekvämt för datoranvändare, men är inte den anpassning som används i MPEG-2 och de flesta videoapplikationer.

Upplösning och bildförhållande

JPEG -standarden innehåller inte någon metod för kodning av bildens upplösning eller bildförhållande. JFIF tillhandahåller information om upplösning eller bildförhållande med en applikationssegmenttillägg till JPEG. Den använder applikationssegment #0, med ett segmentrubrik bestående av den null-avslutade strängstavningen "JFIF" i ASCII följt av en byte lika med 0, och anger att detta måste vara det första segmentet i filen, vilket gör det enkelt att känner igen en JFIF -fil. Exif -bilder som spelats in med digitalkameror innehåller i allmänhet inte detta segment, men uppfyller vanligtvis JFIF -standarden i alla andra avseenden.

Färg rymd

JPEG -standarden som används för komprimeringskodning i JFIF -filer definierar inte vilken färgkodning som ska användas för bilder. JFIF definierar den färgmodell som ska användas: antingen Y för gråskala, eller YCbCr härledd från RGB-färgprimärer enligt definitionen i CCIR 601 (nu känd som Rec. ITU-R BT.601), utom med en annan "full range" skalning av Y-, Cb- och Cr -komponenterna. Till skillnad från "studiointervallet" som definieras i CCIR 601, där svart representeras av Y = 16 och vitt med Y = 235 och värden utanför detta intervall är tillgängliga för signalbehandling "headroom" och "footroom", använder JFIF alla 256 nivåer av 8-bitarsrepresentationen, så att Y = 0 för svart och Y = 255 för toppvit. RGB -färgprimärerna som definieras i JFIF via CCIR 601 skiljer sig också något från vad som har blivit vanlig praxis i nyare applikationer (t.ex. skiljer de sig något från färgprimärerna som definieras i sRGB ). Dessutom gav CCIR 601 (före 2007) ingen exakt definition av RGB -färgprimer. den förlitade sig istället på tv -branschens underliggande praxis.

Färgtolkning av en JFIF -bild kan förbättras genom att bädda in en ICC -profil, färgrymdmetadata eller en sRGB -tagg och använda ett program som tolkar denna information.

Filformatstruktur

En JFIF -fil består av en sekvens av markörer eller markörsegment (för mer information se JPEG, syntax och struktur ). Markörerna definieras i del 1 av JPEG -standarden. Varje markör består av två byte: en FFbyte följt av en byte som inte är lika med 00eller FFoch anger markörens typ. Vissa markörer står ensamma, men de flesta indikerar starten på ett markersegment som innehåller databyte enligt följande mönster:

FF xx s1 s2 [data bytes]

Byte s1 och s2 tas tillsammans för att representera ett 16-bitars heltal med stor endian som specificerar längden på följande "databyte" plus de 2 byte som används för att representera längden. Med andra ord, s1 och s2 anger antalet följande byte som .

Enligt del 1 i JPEG -standarden kan applikationer använda APP -markersegment och definiera en applikationsspecifik betydelse av data. I JFIF -standarden definieras följande APP -markersegment:

  • JFIF APP0 markersegment (JFIF -segment för kort) (obligatoriskt)
  • JFIF -förlängning APP0 markersegment (JFXX -segment för kort) (tillval)

De beskrivs nedan.

JFIF -standarden kräver att JFIF APP0 -markersegmentet omedelbart följer SOI -markören. Om ett JFIF -tillägg APP0 -markersegment används måste det omedelbart följa JFIF APP0 -markersegmentet. Så en JFIF -fil kommer att ha följande struktur:

JFIF -filstruktur
Segmentet Koda Beskrivning
SÅ JAG FF D8 Bildens början
JFIF-APP0 FF E0 s1 s2 4A 46 49 46 00 ... se nedan
JFXX-APP0 FF E0 s1 s2 4A 46 58 58 00 ... valfritt, se nedan
... ytterligare markeringssegment
(till exempel SOF, DHT, COM)
SOS FF DA Start av skanning
komprimerad bilddata
EOI FF D9 Slut på bild

JFIF APP0 markersegment

I det obligatoriska JFIF APP0 -markörsegmentet specificeras bildens parametrar. Eventuellt kan en okomprimerad miniatyrbild bäddas in.

JFIF APP0 markersegment
Fält Storlek (byte) Beskrivning
APP0 -markör 2 FF E0
Längd 2 Segmentets längd exklusive APP0 -markör
Identifierare 5 4A 46 49 46 00= "JFIF" i ASCII , avslutad med en nullbyte
JFIF -version 2 Första byte för större version, andra byte för mindre version ( 01 02för 1.02)
Densitetsenheter 1 Enheter för följande pixeldensitetsfält
  • 00 : Inga enheter; bredd: höjd pixel bildförhållande = Ydensity: Xdensity
  • 01 : Pixlar per tum (2,54 cm)
  • 02 : Pixlar per centimeter
Xdensity 2 Horisontell pixeltäthet. Får inte vara noll
Ydensitet 2 Vertikal pixeltäthet. Får inte vara noll
Xthumbnail 1 Horisontell pixelantal för följande inbäddade RGB -miniatyrbild. Kan vara noll
Miniatyrbild 1 Vertikal pixelantal för följande inbäddade RGB -miniatyrbild. Kan vara noll
Miniatyrdata 3 × n Okomprimerad 24-bitars RGB (8 bitar per färgkanal) raster-miniatyrdata i ordningen R0, G0, B0, ... Rn-1, Gn-1, Bn-1; med n = Xthumbnail × Ythumbnail

JFIF -tillägg APP0 markörsegment

Omedelbart efter JFIF APP0 -markersegmentet kan det finnas ett JFIF -förlängnings APP0 -marksegment. Det här segmentet kan endast finnas för JFIF -versioner 1.02 och senare. Det gör det möjligt att bädda in en miniatyrbild i 3 olika format.

JFIF -tillägg APP0 markörsegment
Fält Storlek (byte) Beskrivning
APP0 -markör 2 FF E0
Längd 2 Segmentets längd exklusive APP0 -markör
Identifierare 5 4A 46 58 58 00= "JFXX" i ASCII , avslutad med en nullbyte
Miniatyrformat 1 Anger vilket dataformat som används för följande inbäddade miniatyrbild:
  • 10 : JPEG -format
  • 11 : 1 byte per pixel palettiserat format
  • 13 : 3 byte per pixel RGB -format
Miniatyrdata variabel Beror på miniatyrformatet, se nedan

Miniatyrdata beror på miniatyrformatet enligt följande:

Miniatyrbild lagrad med JPEG -kodning
Fält Storlek (byte) Beskrivning
SÅ JAG 2 FF D8
variabel Måste vara JIF -format med YCbCr eller bara Y, och får inte innehålla JFIF- eller JFXX -segment
EOI 2 FF D9
Miniatyrbild lagrad med en byte per pixel
Fält Storlek (byte) Beskrivning
Xthumbnail 1 Horisontell pixelantal för följande inbäddade miniatyrbild. Får inte vara noll
Miniatyrbild 1 Vertikalt antal pixlar för följande inbäddade miniatyrbild. Får inte vara noll
Miniatyrpalett 768 256 palettposter, som alla innehåller ett 24 -bitars RGB -färgvärde
Miniatyrdata n En byte per pixel som innehåller färgindexet i paletten,

med n = Xthumbnail × Ythumbnail

Miniatyrbild lagrad med tre byte per pixel
Fält Storlek (byte) Beskrivning
Xthumbnail 1 Horisontell pixelantal för följande inbäddade miniatyrbild. Får inte vara noll
Miniatyrbild 1 Vertikalt antal pixlar för följande inbäddade miniatyrbild. Får inte vara noll
Miniatyrdata 3 × n Okomprimerad 24-bitars RGB (8 bitar per färgkanal) raster-miniatyrdata i ordningen R0, G0, B0, ... Rn-1, Gn-1, Bn-1; med n = Xthumbnail × Ythumbnail

Kompatibilitet

Det nyare utbytbara bildfilformatet (Exif) är jämförbart med JFIF, men de två standarderna är inbördes inkompatibla. Detta beror på att båda standarderna anger att deras specifika applikationssegment (APP0 för JFIF, APP1 för Exif) omedelbart måste följa SOI -markören. I praktiken producerar många program och digitalkameror filer med båda applikationssegmenten inkluderade. Detta kommer inte att påverka bildavkodningen för de flesta avkodare, men dåligt utformade JFIF- eller Exif -parsrar känner kanske inte igen filen ordentligt.

JFIF är kompatibelt med Adobe Photoshop JPEG -tillägg "Information Resource Block" och metadata för IPTC Information Interchange Model , eftersom JFIF inte utesluter andra applikationssegment och Photoshop -tillägg inte behöver vara de första i filen. Men Photoshop sparar i allmänhet CMYK-buffertar som fyra-komponent "Adobe JPEG" som inte överensstämmer med JFIF. Eftersom dessa filer inte har ett YCbCr -färgutrymme kan de vanligtvis inte avkodas av webbläsare och annan Internetprogramvara.

Historia

Utvecklingen av JFIF-dokumentet leddes av Eric Hamilton från C-Cube Microsystems , och avtalet om den första versionen fastställdes i slutet av 1991 vid ett möte som hölls på C-Cube med cirka 40 representanter för olika dator-, telekommunikations- och bildföretag. Kort därefter publicerades en mindre översyn - JFIF 1.01. I nästan 20 år var den senaste versionen tillgänglig v1.02, publicerad 1 september 1992.

1996 specificerade RFC 2046 att bildformatet som används för att överföra JPEG -bilder över internet ska vara JFIF. Den MIME-typ av "image / jpeg" måste kodas som JFIF. I praktiken kan emellertid praktiskt taget all Internet -programvara avkoda alla JIF -avbildningar i baslinjen som använder Y- eller YCbCr -komponenter, oavsett om de är JFIF -kompatibla eller inte.

Med tiden omstrukturerades C-Cube (och slutligen övergick till Harmonic , LSI Logic , Magnum Semiconductor , Avago Technologies , Broadcom och GigOptix, GigPeak, etc) och förlorade intresset för dokumentet, och specifikationen hade ingen officiell utgivare tills den hämtades av Ecma International och ITU-T/ISO/IEC Joint Photographic Experts Group runt 2009 för att undvika att den går förlorad för historien och ger ett sätt att formellt citera den i standardpublikationer och förbättra dess redaktionella kvalitet. Den publicerades av ECMA 2009 som teknisk rapport nummer 98 för att undvika förlust av historiska rekord, och den standardiserades formellt av ITU-T 2011 som sin rekommendation T.871 och av ISO/IEC 2013 som ISO/IEC 10918- 5, De nyare publikationerna innehöll redaktionella förbättringar men inga väsentliga tekniska förändringar.

Se även

Referenser

Vidare läsning

Böcker

Standarder