[poppler] XYZ white point correction patch

[Hal V. Engel]

On Thursday 21 May 2009 01:13:23 pm Albert Astals Cid wrote:
> A Dilluns, 18 de maig de 2009, Hal V. Engel va escriure:
> > On Sunday 17 May 2009 12:44:51 pm Albert Astals Cid wrote:
> > > A Diumenge, 17 de maig de 2009, Hal V. Engel va escriure:
> > > > Here is a patch that will apply the white point correction after a
> > > > call to getXYZ().  This patch can be applied to current git.
> > > >
> > > > Hal
> > >
> > > Do you have a pdf that shows what this fixes?
> > >
> > > Albert
> >
> > #35 on the altona test pdf shows this for the Lab to XYZ conversion.
> > Without the white point correction the difference between the upper right
> > ECI-RGB ICCBased image and the lower left CIELAB image is apparent
> > although it was not a huge difference.  With this fix the difference goes
> > away. This was testing with color management enabled.  This test is NOT
> > valid with color management disabled.
> >
> > I don't have test PDFs for the calRGB or calGray cases.  The altona test
> > PDF does not have any CalRGB or CalGray objects.   The CIE to XYZ
> > conversions do need a white point correction other than CalRGB.  At least
> > that is what is shown in the PDF specification for these conversions.
> >
> > After looking closer just now at the CalRGB to XYZ documentation I see
> > that the CalRGB to XYZ conversion does not use the white point values in
> > the conversion unlike CalGray to XYZ and Lab to XYZ.    But the original
> > code was doing a white point correction but it was dividing by the white
> > point so this was clearly incorrect because the conversion should not do
> > a separate white point correction since this is handled by the matrix.  I
> > made a mistake when I saw the incorrect WP conversion in the CalRGB code
> > and assumed that it should be the same as the CalGray and Lab code when
> > in fact it should have been removed.
> >
> > Also it might be common for these objects to use the default white point
> > of X = Y= Z = 1.0 in which case this will not make any difference.  But I
> > am not sure how common this is and the PDF documentation implies that D65
> > is the recommended WhitePoint ([ 0.9505 1.0000 1.0890 ]) for CalRGB and
> > CalGray.
> >
> > I have attached a new version of the patch that removes all white point
> > corrections from the code for CalRGB.
>
> With #35 you mean the circled 35 in altona_visual_1v2a_x3.pdf ? If so
> pdftoppm generates exactly the same files with your patch and without your
> patch here, so i guess it's not "fixing" anything for me.
>
> Albert
>
> > Hal

Yes the object next to the circled 35 in the bottom right area of 
altona_visual_1v2a_x3.pdf.   

I don't know how it is possible for it to not make any difference at all since 
I can see that it clearly changes the XYZ values after the initial non-white 
point corrected conversion to XYZ.  But the visual difference might be very 
small depending on the output device profile.  The Lab object in the altona 
test pdf has a normalized white point of: 

X = 0.96420 Y = 1.00000 Z = 0.82491

Which is about 5,000K or D50.  So this is significantly different from the 
specifications recommended D65 white point.

In most cases the white point correction will result in a small change in how 
the image is reproduced.   If the white point of the CIELab object is very 
close to the white point of the output device then you would not see any 
difference but if these were significantly different then the difference would 
be visible.  Here with my monitor profile the difference is not huge and it is 
just barely noticeable.

According to the PDF spec. the Y white point value should always be 1.0.  So 
it might be possible to just do the correction to X and Z since this would 
make the code slightly more efficient.  Also I now think it would be better to 
do this in GfxCalGrayColorSpace::getXYZ() and GfxLabColorSpace::setXYZ() 
instead of in the locations right after calls to these functions. 

Hal