Hello Calvin,
my problem is related to the one reported by travis, excepted that I wanted to use JPEGsnoop to show the advantage of splitting the different components in individual scans (or Y alone and Cb Cr together) when odd sizes are involved (MCUs need to be padded with dummy Y data units, separate scans do no require those which leads to smaller files).
Unfortunately JPEGsnoop does not decode the images correctly when a scan does not hold the 3 components.
Technically speaking these kind of JPEGs are still sequential ones, but they share some similarities with progressive ones (a decoder needs to keep entire scans in memory before it can produce actual RGB datas), could you please update JPEGsnoop to handle this type of files?
In this sample Cb & Cr are in the first scan, Y in the second, JPEGsnoop does not expect this, it shocks and displays garbage...
*** Marker: SOF0 (Baseline DCT) (xFFC0)
OFFSET: 0x0000009E
Frame header length = 17
Precision = 8
Number of Lines = 161
Samples per Line = 129
Image Size = 129 x 161
Raw Image Orientation = Portrait
Number of Img components = 3
Component[1]: ID=0x01, Samp Fac=0x22 (Subsamp 1 x 1), Quant Tbl Sel=0x00 (Lum: Y)
Component[2]: ID=0x02, Samp Fac=0x11 (Subsamp 2 x 2), Quant Tbl Sel=0x01 (Chrom: Cb)
Component[3]: ID=0x03, Samp Fac=0x11 (Subsamp 2 x 2), Quant Tbl Sel=0x01 (Chrom: Cr)
*** Marker: SOS (Start of Scan) (xFFDA)
OFFSET: 0x00000119
Scan header length = 10
Number of img components = 2
Component[1]: selector=0x02, table=1(DC),1(AC)
Component[2]: selector=0x03, table=1(DC),1(AC)
Spectral selection = 0 .. 63
Successive approximation = 0x00
*** Marker: SOS (Start of Scan) (xFFDA)
OFFSET: 0x000013F4
Scan header length = 8
Number of img components = 1
Component[1]: selector=0x01, table=0(DC),0(AC)
Spectral selection = 0 .. 63
Successive approximation = 0x00
I wanted to show that the large hidden part of the image shown here on an MCU based (3 components in a single scan) is smaller (and overall file size is smaller) when separate scans are used, but...
Hello Calvin, my problem is related to the one reported by travis, excepted that I wanted to use JPEGsnoop to show the advantage of splitting the different components in individual scans (or Y alone and Cb Cr together) when odd sizes are involved (MCUs need to be padded with dummy Y data units, separate scans do no require those which leads to smaller files). Unfortunately JPEGsnoop does not decode the images correctly when a scan does not hold the 3 components.
Technically speaking these kind of JPEGs are still sequential ones, but they share some similarities with progressive ones (a decoder needs to keep entire scans in memory before it can produce actual RGB datas), could you please update JPEGsnoop to handle this type of files?
In this sample Cb & Cr are in the first scan, Y in the second, JPEGsnoop does not expect this, it shocks and displays garbage...
I wanted to show that the large hidden part of the image shown here on an MCU based (3 components in a single scan) is smaller (and overall file size is smaller) when separate scans are used, but...
The image itself:
Archive with more material: http://frdx.free.fr/ycc4calvin.zip
Regards
[2013/06/24] First created at https://sourceforge.net/p/jpegsnoop/feature-requests/42/ by Frédéric Kayser