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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/poppler _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
