[gs-bugs] [Bug 691922] Slightly wrong colors on RGBW model

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Wed Feb 2 07:57:46 UTC 2011


http://bugs.ghostscript.com/show_bug.cgi?id=691922

--- Comment #8 from Oldřich Jedlička <oldium.pro at seznam.cz> 2011-02-02 07:57:42 UTC ---
My tool just extracts the RGB and W part one-to-one, I've written it from
scratch. There is no color correction, no calculations, so the bitmaps are
exactly the same as in the raster file. This is contrary to the debug output of
hplip, which writes the bitmap files after correction.

My personal expectation is that the W part takes the color "darkness" and the
RGB part takes the rest. For example the Gray Ramp could be completely white in
the RGB part, but should be perfectly visible in the W part.

Just have look at the Gray Ramp with Gimp or so. I would not expect that the
darkest color is RGB 71,82,84 and W 30. This looks wrong, the W part should
take the full "darkness"; the RGB values after translating from RGBW would be
-154,-143,-141. I would expect that RGB is 255,255,255 and W 0.

The negative values cause problems in hplip (it uses unsigned byte values, so
the value overflows) when it translates RGBW into RGB model and completely
black pixels - I've reported this already. Anyway, fix in hplip would not fix
the overflows in the source raster.

Anyway, I will try to generate some simpler test case (gray ramp and some color
wheel) with Gimp and with Inkscape to have a clear starting point for image and
vector-based drawing.

I will try to attach the raster from older Ghostscript too, but this used to
work and there are reports in Gentoo bugs that it works with older version.

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


More information about the gs-bugs mailing list