BGRA Jpg incorrectly decoded.

[Drake53]

Prerequisites

• I have written a descriptive issue title
• I have verified that I am running the latest version of ImageSharp
• I have verified if the problem exist in both DEBUG and RELEASE mode
• I have searched open and closed issues to ensure it has not already been reported

Description

Trying to load a .jpg file with BGRA data gets incorrectly decoded as if it's YCbCr. As a result, the colours are incorrect and there's no alpha channel.

Steps to Reproduce

Simply load the example .jpg file:
https://github.com/Drake53/War3Net/blob/master/tests/War3Net.Common.Testing/TestData/Blp/VillageFallStonePath.jpg

Note that github doesn't display it correctly either, it should look like this:
https://github.com/Drake53/War3Net/blob/master/tests/War3Net.Common.Testing/TestData/Blp/VillageFallStonePath.png

System Configuration

• ImageSharp version: 1.0.3
• Other ImageSharp packages and versions:
• Environment (Operating system, version and so on):
• .NET Framework version: .NET 5.0
• Additional information:

[br3aker]

If I got you right, you have an bgra image encoded via jpeg format, right?

Jpeg doesn't support bgra format;

Images encoded with four components are assumed to be CMYK, with (0,0,0,0) indicating white unless the image contains an APP14 marker segment as specified in 6.5.3, in which case the colour encoding is considered either CMYK or YCCK according to the application data of the APP14 marker segment. The relationship between CMYK and YCCK is defined as specified in clause 7.

May I ask you where did you re-encode png -> jpeg with bgra colorspace?

[Drake53]

The jpeg data comes from a .blp file, which is a file format that contains embedded jpeg or dds images and supports mipmaps.
https://github.com/Drake53/War3Net/blob/master/tests/War3Net.Common.Testing/TestData/Blp/VillageFallStonePath.blp

I'm not familiar with jpeg specifications, all I know is that using BitmapSource I am able to decode the .jpg correctly.
https://github.com/Drake53/War3Net/blob/master/src/War3Net.Drawing.Blp/BlpFile.cs

However, WPF is windows only, so I'd prefer to use a cross-platform library instead.

[brianpopow]

The color space of this image is CMYK. It has no APP14 marker and has 4 components. I think we are just missing a check, if the adobe marker has its default value?

ImageSharp/src/ImageSharp/Formats/Jpeg/JpegDecoderCore.cs

Line 378 in 9b09775

return this.adobe.ColorTransform == JpegConstants.Adobe.ColorTransformYcck

[br3aker]

@brianpopow seems like. Should be something like this:

return !this.adobe.Equals(default) && this.adobe.ColorTransform == JpegConstants.Adobe.ColorTransformYcck
                    ? JpegColorSpace.Ycck
                    : JpegColorSpace.Cmyk;

Not sure checking if entire struct is default is a good solution though, maybe it's better to do a switch with throw ImageFormatException on default? Right now entire color deduction can pass without a warning if image has some invalid colorspace data.

[brianpopow]

Still does not look as expected with CMYK:

but it looks the same when i convert it with imagemagick to a png.

[JimBobSquarePants]

Does the image contain a color profile?

[brianpopow]

Does the image contain a color profile?

no, there is no color profile

[JimBobSquarePants]

Odd. Try decoding it to rgb. I’m amazed WPF can decode it since it’s seems off spec.

[brianpopow]

looks pretty much the same, except the black area is white.

imagemagick identify says it should be CMYK

[JimBobSquarePants]

https://www.hiveworkshop.com/threads/blp-specifications-wc3.279306/

blp is pretty messed up. WCF must fall back to BGRA once it exhausts all standard possibilities.

[br3aker]

imagemagick identify says it should be CMYK

It's a specification-complient fallback for 4-component image without APP14 marker.

Jpeg simply does not support alpha channels, Jpeg2000 does.

Link provided by @JimBobSquarePants even states that blp jpeg content type had some custom code via framework. I've failed to find anything related to it so it's impossible to say anything about how given file was produced.

Blizzard uses the now discontinued Intel Imaging Framework to produce/decode the JPEG content meaning that each jpegHeaderChunk of official BLP files contains its signature.

Played a bit with the binary, provided .blp file is basically a container with jpeg at the top and something else after the image, it has an explicit valid SOI -> ... -> EOI marker sequence which leads to exact same jpeg provided by the OP. It has 4 components, nothing else -> it's a CMYK file according to jpeg specification. Photoshop, JPEGSnoop, Forensically and internet browsers treat this as a CMYK image.

If it's really a bgra image, CMYK components should store BGRA data in each channel so the only viable solution atm is (simplified):

foreach pixel in decodedImage:
    newImage[i] = new BGRA(pixel.C, pixel.M, pixel.Y, pixel.K)

---

Decoding such 'custom' jpeg images is actually possible with decoder change in #1694. Decoding is done by a virtual method of an internal class which can be exposed to the end user. Question is: do you guys want it to be exposed for cases like this? @JimBobSquarePants @brianpopow

[JimBobSquarePants]

Let me do some research. I want to figure out how JpegBitmapDecoder works.

[br3aker]

@JimBobSquarePants It does not work with given image, following code prints Decoder format: Cmyk32:

const string pathTemplate = "path\\{0}.jpg";

using Stream inputStream = File.Open(string.Format(pathTemplate, "VillageFallStonePath"), FileMode.Open);

var decoder = new JpegBitmapDecoder(inputStream, BitmapCreateOptions.PreservePixelFormat, BitmapCacheOption.Default);

Console.WriteLine($"Decoder format: {decoder.Frames[0].Format}");

Saving it with JpegBitmapEncoder produces the same image:

var encoder = new JpegBitmapEncoder();
encoder.Frames.Add(decoder.Frames[0]);

using Stream outputStream = File.Open(string.Format(pathTemplate, "re_VillageFallStonePath"), FileMode.OpenOrCreate);
encoder.Save(outputStream);

This image was encoded via the code above:
https://user-images.githubusercontent.com/20967409/130426883-3632f04e-94e8-43c2-aecc-2d33aa7fd023.jpg