Repository navigation
Jpeg image decoded as grayscale #464
Description
Activity
Thanks @denisivan0v for all the info and the sample program. We really, really, appreciate it when people like you make the extra effort. 👍
@antonfirsov This is an odd one.
JpegSnoop is reporting a YCCK color profile same as our YCCK sample in the repo so I don't know off the top of my head what the cause would be.
*** Marker: APP14 (xFFEE) *** OFFSET: 0x00000014 Length = 14 DCTEncodeVersion = 25600 APP14Flags0 = 0 APP14Flags1 = 0 ColorTransform = 2 [YCCK]Could you have a look when you can?I'm not gonna have a chance for at least a week and a half.
Maybe I can check this in the next few days. Will definitely do it for beta3.
Reacted by James Jackson-SouthI've just checked this using the PDFJS port and it decodes correctly. I should be able to use it as a reference for the Golang one.
Reacted by Denis IvanovOk.... The conversion algorithm itself looks correct, the input data less so.
For
[0,0]thekvalue should be255but we're getting128. The Golang port is simply too complicated for me to understand without a lot of picking apart and testing so I don't know why that is the case. Maybe we are pulling the wrong component list somehow.cbandcrare both128.I still find the readability of that decoder an issue. I only wish we'd managed to make the other one a bit faster, I've forgotten most of the code I wrote for it but I could understand the pipeline more.
jpeg is hard
☹️ @JimBobSquarePants I will also try to check it as soon as I'm finished with the
MemoryManagerstuff.Can you point me to the code parts you investigated? ("
kvalue")@antonfirsov Yeah of course.
The PDFJs method that I used to determine the correct
kvalue is here.For the Golang port we are looking here.
Using the sample image we should get input YCbCrk values for each component at
[0,0]of0, 128, 128, 255which when converted to RGBA gives us white. The Golang values are0, 128, 128, 128.@JimBobSquarePants as far as I understand, the conversion methods are correct in both decoders, they are just consuming the wrong
kin the "golang" case. I guess the "golang" spectral data is wrong for the input provided in this issue (the "pdfjs" one is inaccurate for others).We have these tests to verify the spectral coefficients produced in the stream parsing phase directly against libjpeg-turbo launched as a separate process (windows only execution).
Currently the pdfjs spectral test cases are skipped (many failing!) but you can enable them to play around. For the input in this issue I expect the opposite:
pdfjs fails & golang succeeds. I mean: golang fails pdfjs succeeds - seems like bed time for me! :)Any further investingation, or even a branch with new failing spectral tests is a progress IMO 😄
@JimBobSquarePants as far as I understand, the conversion methods are correct in both decoders, they are just consuming the wrong k in the "golang" case. I guess the "golang" spectral data is wrong for the input provided in this issue (the "pdfjs" one is inaccurate for others).
@antonfirsov Yeah that's right, the maths is correct, just the input is funky. I'll see what I can do.
- added a commit that references this issue
on Feb 28, 2018 - added a commit that references this issue
on Feb 28, 2018
Prerequisites
DEBUGandRELEASEmodeDescription
There is an CMYK
jpgimage that decodes successfully with ImageSharp, but after encoding it back asjpg(orpng) it becomes grayscale.When converting this image to RGB with ImageMagick, colors are little bit changed but it remains colorful.
Steps to Reproduce
Here is the repro project with the sample image included GrayscaleRepro.zip.
System Configuration
1.0.0-beta0002