Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Determining color space for JPEG

I am writing a code for determining a JPEG image's color space. I have found two references that may help me implementing this. One is on the oracle.com, the other one is a C source code from the ijg.com which "is responsible for the reference implementation of the original JPEG standard".

However they do differ. E.g. in IJG when there is no Adobe marker and there are 4 channels it is assumed as CMYK, but in oracle it is YCCA. Also IJG's implementation doesn't look on subsampling, whereas for 4-channel subsampled it is YCCK in oracle specs, and so on.

Also there are many missings in ColorSpace class, when I implemented the oracle's logic I needed to specify 3 extra color spaces, like YCCK, YCCA, RGBA.

Another point is that I found information that JPEG does not support transparency in alpha channel here, why would oracle talk about YCCA and RGBA in the context of JPEG metadat specification?

In result when checking an image with IJG's logic it tells me it is CMYK (checked the image with ImageMagick on ubuntu and it also says it is CMYK), with oracle's logic it is YCCA. Who to believe? Why would oracle not rely on the original JPEG specification? Or there is something else I don't know?

like image 839
tobi Avatar asked Jun 11 '18 12:06

tobi


2 Answers

I have struggled to understand the Oracle document you refer to as well.

In my experience, from writing a JPEG plugin for Java ImageIO, the right thing to do, is to follow the IJG implementation. That's what the majority of software does, so it will create the least confusion among your users (ie. "Why does my image look different in your software and software X?"). The Sun/Oracle algorithm disagrees with the "rest of the world" in many cases.

I ended up implementing a slightly different algorithm, that takes the "extra" Java color spaces into account, but otherwise stays very close to the IJG implementation:

// Adapted from libjpeg jdapimin.c:
// Guess the input colorspace
// (Wish JPEG committee had provided a real way to specify this...)
switch (startOfFrame.componentsInFrame()) {
    case 1:
        return JPEGColorSpace.Gray;
    case 2:
        return JPEGColorSpace.GrayA; // Java special case: Gray + Alpha
    case 3:
        if (jfif != null) {
            return JPEGColorSpace.YCbCr; // JFIF implies YCbCr
        }
        else if (adobeDCT != null) {
            switch (adobeDCT.transform) {
                case AdobeDCT.Unknown:
                    return JPEGColorSpace.RGB;
                case AdobeDCT.YCC:
                    return JPEGColorSpace.YCbCr;
                default:
                    // TODO: Warning!
                    return JPEGColorSpace.YCbCr; // assume it's YCbCr
            }
        }
        else {
            // Saw no special markers, try to guess from the component IDs
            int cid0 = startOfFrame.components[0].id;
            int cid1 = startOfFrame.components[1].id;
            int cid2 = startOfFrame.components[2].id;

            if (cid0 == 1 && cid1 == 2 && cid2 == 3) {
                return JPEGColorSpace.YCbCr; // assume JFIF w/out marker
            }
            else if (cid0 == 'R' && cid1 == 'G' && cid2 == 'B') {
                return JPEGColorSpace.RGB; // ASCII 'R', 'G', 'B'
            }
            else if (cid0 == 'Y' && cid1 == 'C' && cid2 == 'c') {
                return JPEGColorSpace.PhotoYCC; // Java special case: YCc
            }
            else {
                // TODO: Warning!
                return JPEGColorSpace.YCbCr; // assume it's YCbCr
            }
        }

    case 4:
        if (adobeDCT != null) {
            switch (adobeDCT.transform) {
                case AdobeDCT.Unknown:
                    return JPEGColorSpace.CMYK;
                case AdobeDCT.YCCK:
                    return JPEGColorSpace.YCCK;
                default:
                    // TODO: Warning!
                    return JPEGColorSpace.YCCK; // assume it's YCCK
            }
        }
        else {
            // Saw no special markers, try to guess from the component IDs
            int cid0 = startOfFrame.components[0].id;
            int cid1 = startOfFrame.components[1].id;
            int cid2 = startOfFrame.components[2].id;
            int cid3 = startOfFrame.components[3].id;

            if (cid0 == 1 && cid1 == 2 && cid2 == 3 && cid3 == 4) {
                return JPEGColorSpace.YCbCrA; // Java special case: YCbCrA
            }
            else if (cid0 == 'R' && cid1 == 'G' && cid2 == 'B' && cid3 == 'A') {
                return JPEGColorSpace.RGBA; // Java special case: RGBA
            }
            else if (cid0 == 'Y' && cid1 == 'C' && cid2 == 'c' && cid3 == 'A') {
                return JPEGColorSpace.PhotoYCCA; // Java special case: YCcA
            }
            else {
                // TODO: Warning!
                // No special markers, assume straight CMYK.
                return JPEGColorSpace.CMYK;
            }
        }

    default:
        throw new IIOException("Cannot determine source color space");
}
like image 67
Harald K Avatar answered Sep 20 '22 16:09

Harald K


After my comments on old JPEG standards, I finally found the answer.

On ISO/IEC 10918-6:2013 (E), section 6.1:

  • Images encoded with only one component are assumed to be grayscale data in which 0 is black and 255 is white.

  • Images encoded with three components are assumed to be RGB data encoded as YCbCr unless the image contains an APP14 marker segment as specified in 6.5.3, in which case the colour encoding is considered either RGB or YCbCr according to the application data of the APP14 marker segment. The relationship between RGB and YCbCr is defined as specified in Rec. ITU-T T.871 | ISO/IEC 10918-5.

  • 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.

and the APP14 flags is "Adobe\0", the AP12 has the transform flag:

Transform flag values of 0, 1 and 2 shall be supported and are interpreted as follows:

0 – CMYK for images that are encoded with four components in which all four CMYK values are complemented; RGB for images that are encoded with three components; i.e., the APP14 marker does not specify a transform applied to the image data.

1 – An image encoded with three components using YCbCr colour encoding.

2 – An image encoded with four components using YCCK colour encoding.

So, it depends: It should be CMYK, but it could be YCCK if APP14 and AP12 have the right values.

like image 39
Giacomo Catenazzi Avatar answered Sep 19 '22 16:09

Giacomo Catenazzi