19 of the files shows slight darker/light grays converting pxl->png vs direct png (or pxl->pnm vs pnm). see 0670, the gray strip on the right, in most of the panels in that file, for example. fts.0670 fts.0800 fts.0810 fts.0825 fts.0832 fts.0844 fts.0853 fts.0861.new fts.0861 fts.0862 fts.0865 fts.0970 fts.0980 fts.0982 fts.2020 fts.2024 fts.2092 fts.2320 fts.2354 Using something like this in a shell script: pcl6 -dNOPAUSE -sDEVICE=png16m -sOutputFile=a-${1}.png $1 pcl6 -dNOPAUSE -sDEVICE=pxlcolor -r72 -sOutputFile=a.pxl $1 pcl6 -dNOPAUSE -sDEVICE=png16m -sOutputFile=b-${1}.png a.pxl compare a-${1}.png b-${1}.png diff-${1}.png I don't know where the disagreement is nor which side is correct, but likely some inconsistent red=green=blue for gray and actual luminance conversion (somewhat bias in green) at some point.
This is split out from Bug 690585 - pxlcolor bugs, BTW.
Sorry, excluding fts.0980, fts.0982 (bug 693054). Only 17 files.
Assigning this to Henry who'll probably reassign it to Michael.
These high level devices should not be color managed, presumably the colors should be passed straight through and we would assume the consumer of the XL output would do the color management. Speaking with Michael the flag -dUseFastColor should workaround this until we have a nicer solution but I haven't tested it. This should be a default flag for pxlcolor and pxlmono. I don't know if that is an easy fix for distributions - to have device specific flags, I copied in Till.
Sigh UseFastColor does not seem to matter so something else is happening here.
Looking at the first raster in fts.0670 (PCL file) the gray is actually specified in RGB (226,226,226) and passed through to the device without change. The XL device punts on the raster and draws a rectangle but notices the RGB can be represented with a Gray colorspace. So it create a rectangle with gray color 226, now when we render that gray rectangle with an RGB device the default gray profile maps 226 to something else. Values normalized to 65535 the mapping is as follows. remap [ 58082 ] --> [ 59541 59550 59539 ] I don't think there is really a problem here, the optimization to gray in the XL device seems reasonable and clearly the gray profile can't always map back to the original color, so I would say round tripping is simply not possible all the time. I copied in Michael to see if the color values are as he expects. Why do we need this to work Hin-Tak, for regression testing?
(In reply to comment #6) > Why do we need this to work Hin-Tak, for regression testing? I suppose you can build some sort of color-shift/gray-shift tolerance to regression testing?
(In reply to comment #6) >... Values normalized to 65535 > the mapping is as follows. > > remap [ 58082 ] --> [ 59541 59550 59539 ] That looks a bit wrong - if it were doing lumina transform of some sort, the outputs should "average" somehow to the original. All three values are higher than the original, in the above.
Well in any event the PCL Department is done with this problem, I'll move it along to Marcos in case it is messing up his regression tests. If one always used -dUseFastColor=true when "round tripping" the files will work because the gray won't be transformed by the icc profile. I recommend that be used with XL regression testing if we are going from the output XL back to raster for comparison purposes.
Just for reference: 226 == 0xE2 58082 == 0xE2E2 so 58082 looks right for the resulting gray value. For comparison: :; transicc -ewx -i /usr/share/ghostscript/9.06/iccprofiles/default_gray.icc -o /usr/share/ghostscript/9.06/iccprofiles/default_rgb.icc LittleCMS ColorSpace conversion calculator - 4.2 [LittleCMS 2.04] Enter values, 'q' to quit G? 226 R=0xE896 G=0xE89F B=0xE894 Enter values, 'q' to quit G? 226.886275 R=0xE950 G=0xE959 B=0xE94E Enter values, 'q' to quit G? q Done. (The latter value is 0XE2.E2E2E2E2E2E2E2E3P+0.) Going from sgray.icc to srgb.icc is the same. The non-uniform sgray->srgb conversion does not occur if you leave off the -o option to transicc (which uses an internal srgb default), so the non-uniform aspect is due to the details of the two icc profile files. The lightening may be as well. Going the other direction with gs’s profiles, rgb (226,226,226) convers to 0xDBE4. Perhaps default gray to default rgb and explicit sgray to srgb conversions shouldn’t go via the profiles? Or the r=g=b → gray simplification should start using the profiles? Either option would round-trip, at least for the twelve or so more significant bits. Side note: gs should add a “default_k” profile which does to/for its default_cmyk what default_gray does to/for its default_rgb. Or maybe call it swoppy_gray ☺.
This should have been reassigned to Marcos upon the entry of Comment #9.
(In reply to comment #9) > Well in any event the PCL Department is done with this problem, I'll move it > along to Marcos in case it is messing up his regression tests. If one > always used -dUseFastColor=true when "round tripping" the files will work > because the gray won't be transformed by the icc profile. I recommend that > be used with XL regression testing if we are going from the output XL back > to raster for comparison purposes. The nightly/weekly regression tests only compare the generated bitmap to the previous bitmap, therefore any shift in color values isn't an issue. We have run "run trip" comparisons before, but in those cases we've used a tolerance as to what constitutes a match.