SOF0 marker component 0 id should be 82 but 1 was presented

[wolfviking0]

I am facing an issue in my code, but I have a difficulty to understand what trigger it.

I am just trying to uncompress a JPG, I have various information regarding the texture :

[INFO] Size : 7077888
[INFO] Compressed : 1 - Size : 1755787 <- std::vector<uint8_t>
[INFO] Width : 1536
[INFO] Height : 1536
[INFO] Channels : 3
[INFO] Format : RGB8

But for some reason I received this error:
[GPUJPEG] [Error] SOF0 marker component 0 id should be 82 but 1 was presented!
[GPUJPEG] [Error] Decoder failed when decoding image data!

Can you told me when this message can be trigger ?

Thanks

[MartinPulec]

Sure, the image channels have numeric IDs, usually Y = 0, Cb = 1, Cr = 1, R = (int) 'R', G = (int) 'G', R = (int) 'B'. For your image, it is detected RGB from APPx marker (perhaps APP14, but it might be also a SPIFF header) but the components IDs are different - 0,1,2 I guess - if you paste the image, I might be able to tell more).

If you turn the respective error in code to warning (commenting out this line) it may work (it is just a check - RGB will be assumed). I am just unsure why the first component has ID 1 - I would understand 0, but 1 seems is a bit suspicious to me. It may be OK, but the interpretation may be different as well. Again, if you paste the image, I could look at it (and perhaps adapt GPUJPEG for that).

EDIT (2021-01-05): Crossed text was wrong - I didn't remember that correctly, JPEG usually uses 1, 2 and 3 for Y, Cb, Cr (1-based indices).

[wolfviking0]

So here the trouble, it could be an incorrect use of the library, but I am using only one Decoder with RGB colorspace.

But sometime I received JPG with YUV_JPEG inside so, I am just updating the param and use the same decoder after calling gpujpeg_decoder_set_output_format
After doing this behavior few times its trigger this issues.

I don't have a sample but here how I think you can reproduce.

• create param and param image default

• create decoder

• forloop

  • update decoder for rgb
  • decompress rgb
  • update decoder for yuv
  • decompress yuv

  After few iteration I have the S0F0 marker issue.
  I will try to give you a real sample :)

[MartinPulec]

Hi @wolfviking0, I can confirm that your proposed steps to reproduce really reveal the issue, namely using the command-line app:

gpujpeg -d rgb.jpg out.rgb yuv.jpg out.rgb

with input JPEGs with the corresponding color spaces.

[MartinPulec]

I've partially fixed that with commit 593c423. Now it correctly detects the color space from the presence of JFIF header (it allows YCbCr only), which is the case for most JPEGs.

The situation when it will not work are JPEGs without an identifying header - eg. FFmpeg produces JPEGs without JFIF header. Here is not sane to assume that it is YCbCr. On the other hand, the component ID may be used to deduce the color space then - I'll investigate that further.

[MartinPulec]

I've pushed some other related changes (up to commit 4dd775f). It further improves the behavior - if the color space cannot be identified from headers (eg. those FFmpeg JPEGs), it is deduced from component IDs (only RGB/YCbCr distinction, YCbCr 709 can be pre-set by setting gpujpeg_parameters::color_space_internal). On contrary, if header and component ID do not match, header color space is preferred and only warning is displayed (but decoding proceeds).

[wolfviking0]

@MartinPulec Thanks for your changes, I run few days the code with your latest master and so far I do not have any issue anymore :)

I think we can close this one. Thanks again.