Color space YCBCR to RGB problem: resulting image is PINK

Hello everyone,

Here is the workflow.

1. Load the RGB image
2. Convert the color space from RGB to YCbCr
3. Process the 3 different components (Luminance Y and chrominance Cb/Cr)
4. Convert the color space back to RGB
5. Display the image (result displayed is PINK).

You can find the resulting image attached.

Here are some indications about the YCBCR image before and after the processing. [Max] (Y,Y'):(235, 362.6280) [Min] (Y,Y'):(19.85 , 10.47)

[Max] (Cb,Cb'):(142.04 , 211.74) [Min] (Cb,Cb'):(100.04 , 95.1551)

[Max] (Cr,Cr'):(165.12 , 247.92) [Min] (Cr,Cr'):( 118.5728 , 107.0473)

(Y, Cb, Cr): original components in YCbCr color space (Y', Cb', Cr'): enhanced components in YCbCr color space

[Sangeetha Jayaprakash]

1. What is the format of the image you are loading?

2. I assume you are using "imread" to load the image in MATLAB. What are the dimensions of the resulting array from "imread"?

Answer 1

[DGM]

Without knowing what processing was being performed, it's hard to say exactly what's going on. Even having the original image would have been helpful.

There is enough information to suggest that most of the image data is being pushed way out of gamut, and the data is also improperly-scaled for its class.

This is the projection of sRGB into uint8-scale YCbCr. If your image data is not inside this volume upon conversion back to RGB, it will be mapped back to the gamut boundary on a trajectory which is normal to the illustrated surface. This tends to move color points toward the corners and edges of the RGB cube. It should be no surprise to find everything compressed toward white and magenta.

From the given input/output extrema, we could presume that we can calculate a linear transformation. The problem with that is the difficulty in finding a test image which has a narrow enough color range to survive such an extreme transformation without slamming every single pixel to [1 0 1]. Let's just assume an approximate scaling factor based on the swings we see. That should be enough to make the point.

% this image has similar color range
inpict = imread('llama.jpg');

% rescale somehow in YCC
ycc = rgb2ycbcr(inpict); % uint8-scale YCbCr
ycc = ycc*1.5; % scale all channels by ~1.5

% convert back
outpict = ycbcr2rgb(ycc); % uint8-scale RGB

imshow(outpict,'border','tight')

While our color distribution started out here

... it all gets shoved over here (illustrated in float to avoid truncation).

From the given extrema, we can also see that the data is floating-point. If ycbcr2rgb() is given floating-point data, it expects it to be properly-scaled for its class -- just as rgb2ycbcr or other functions expect of RGB images.

% this image has similar color range
inpict = imread('llama.jpg');

% just use improperly-scaled YCC
ycc = rgb2ycbcr(inpict); % uint8-scale YCbCr
% don't change the values at all, but change the class
ycc = double(ycc); % now it's uint8-scale, but not uint8

% convert back
outpict = ycbcr2rgb(ycc); % uint8-scale RGB

imshow(outpict,'border','tight')

So what went wrong in all the unseen mystery code? Everything got pushed out of gamut somehow, and the results are as should be expected.

I'm also not sure if OP realized that the neutral axis is not at (Cb,Cr) = (0,0).

[DGM]

FWIW, these would be the parameters of the calculated linear transformation if we were to take the extrema as representative.

% ycc1 = k.*ycc0 + os;
ycc0 = [19.85 100.04 118.57; 235 142.04 165];
ycc1 = [10.47 95.155 107.05; 362.63 211.74 247.92];

for c = 1:3
    x(:,c) = [ycc0(1,c) 1; ycc0(2,c) 1]\[ycc1(1,c); ycc1(2,c)];
end

k = x(1,:)

scalingfactors = 1×3

1.6368 2.7758 3.0340

os = x(2,:)

offsets = 1×3

-22.0207 -182.5394 -252.6949

So yes, it would be pretty extreme.