Repository navigation
Jpeg loaded with pink color blur #2174
Description
Activity
The image has 3 components with no subsampling, that's why ImageSharp deduces the colorspace to RGB. It seems it should be YCbCr instead, but I am not sure how we can come to this conclusion from the components info's. The component Id's are 0, 1 and 2.
I wish the jpeg spec would define the color space properly. This guessing the colorspace from the component info's really gets out of hand.
The image has 3 components with no subsampling, that's why ImageSharp deduces the colorspace to RGB. It seems it should be YCbCr instead, but I am not sure how we can come to this conclusion from the components info's. The component Id's are 0, 1 and 2.
Actually it should be ycbcr regardless of the components' ids: 3 components without APP14 marker is YCbCr. RGB colorspace is defined by App14 marker with
flag=0.AFAIR we had this check did we change it some time ago?
P.S.
First time seeing [0, 1, 2] components' ids. It's usually [1, 2, 3] for ycbcr or [82,71,66] for rgb. Most likely we have some colorspace deduction based on ids.Actually it should be ycbcr regardless of the components' ids: 3 components without APP14 marker is YCbCr. RGB colorspace is defined by App14 marker with flag=0.
@br3aker: The colorspace is determined as RGB, because it has 3 components and no subsampling, but it also has no APP14 marker. So this seems wrong then. It was introduced with #2124, with commit: 89668a6.
So this seems wrong then. It was introduced with #2124, with commit: 89668a6.
I guess we just need to remove final if check here and return ycbcr as a fallback colorspace:
ImageSharp/src/ImageSharp/Formats/Jpeg/JpegDecoderCore.cs
Lines 534 to 540 in e7a10b0
Oh wait, it's actually an app14 code path.
Colorspace deduction is done here:
IMO we should remove any id-based deduction:
if(has App14) { // current logic works fine } else { // spec doesn't say anything about id-based color deduction // [1, 2, 3] == YCbCr worked before but image from this issue // has [0, 1, 2] ids and yet is completely valid according to the spec // AFAIR adobe spec about jpeg colorspace defines RGB colorspace // only if App14 is present return ColorSpace.YCbCr; }Reacted by James Jackson-SouthWas just reading through the decoder there as the condition looked incorrect. Agreed on the fix.
I'll open PR today.
Reacted by Brian PopowReacted by James Jackson-South
Prerequisites
DEBUGandRELEASEmodeImageSharp version
2.1.2
Other ImageSharp packages and versions
2.1.3, 3.0.0-alpha.0.11, 3.0.0-alpha.0.21
Environment (Operating system, version and so on)
Windows 10 21H1 x64
.NET Framework version
.Net 6.0
Description
We stumbled on a Jpeg image that gets loaded with wrong colors on all versions after 2.1.1. Tested with 2.1.2, 2.1.3, 3.0.0-alpha.0.11 and 3.0.0-alpha.0.21.
This is very similar to issues #2133, #2141 and #2152. However we don't think it's a duplicate since it's not fixed in either 2.1.3 (like #2133) or 3.0.0-alpha.0.11 (like #2141 / #2152).
Steps to Reproduce
This NUnit test passes on 2.1.1 and fails on all later versions with "Expected: Rgba32(255, 255, 255, 255) But was: Rgba32(255, 128, 128, 255)".
Images
We don't own the problematic image so we can't distribute it. You can download it and use it as a starting point to create another image with the same properties.