fix: update ijg jpeg lib to v9f, partially fixes DEV-3474 #449
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As far as I understand, the core of the issue is that the ijg library used not to correctly recognize when the 4 channel colorspace is actually YCCA, which is likely (but I can't say with 100% certainty) fixed in v9e: libjpeg-turbo/ijg@ff9491d#diff-71516311e7ecc262ab53731fc7ec0ea1c6d50ff9367bdea67804f9af5c9015e5L165-R180I discovered where the bug lies after checking that the values of a image of just cyan (100%, 0%, 0%, 0%) are 0, 255, 255, 255, so it could not have been the fault of the image profile convertor (LittleCMS, in this case. In addition, I tried setting all the parameters for LCMS manually and tested it with a byte array, which was all correct.)Knowing the root cause, additional reports of such problems can be found, because this feature space is dependent on vendor markers and likely not tested as extensively.With the ijg lib updated to v9f, the original file attached in the issue is getting converted correctly, although files converted with imagemagick still remain black.