Re: [Gimp-print-devel] Handling "inverted" CMY data?

[Michael M. <mic...@li...>]

Solomon Peachy wrote:
% When adding support for the various Kodak printers, my determination of 
% CMY or RGB data is based on the levels used for black text on the 
% printer test page.  If the "white level" is 0xff, then it's presumably 
% RGB data, and if it's 0x00, it's presumably RGB.
% 
% This assumption is baked into gutenprint.  Unfortunately I think the 
% Kodak 1400/805/9810 printers don't work this way.  The white level is 
% 0xff, but the image data appears to be CMY rather than RGB, judging on 
% the channel data from the windows test page.

How does that "Kodak CMY" differ from normal CMY? I mean in terms of
basic colors, e.g.

        CMY     RGB     "Kodak CMY"
white   000000  ffffff  ?      
black   ffffff  000000
red     00ffff  ff0000
green   ff00ff  00ff00
blue    ffff00  0000ff
cyan    ff0000  00ffff
magenta 00ff00  ff00ff
yellow  0000ff  ffff00
        
% I don't think there's any existing mechanism in gutenprint for handling 
% this.  I was thinking of adding a DYESUB_FEATURE_DATA_INVERTED flag that 
% will invert pv.empty_byte and the individual pixel data in 
% dyesub_print_pixel().
% 
% Thoughts?
% 
%  - Solomon
% -- 
% Solomon Peachy        		       pizza at shaftnet dot org	 

--
Michael Mráka