[poppler] XYZ white point correction patch

[Albert Astals Cid]

A Divendres, 22 de maig de 2009, Hal V. Engel va escriure:
> 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.

When i mean no difference i mean "diff" says the files are exactly the same, 
not that i'm not able to see a difference in them.

May it be because i'm not using any color profile?

Albert

>
> Hal
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler