[Gimp-print-devel] Question about internal color conversion and gamma flow

[Solomon P. <pi...@sh...>]

I'm trying to (finally) hunt down the root cause of persistant (and 
consistant) reports of dyesub color output not aligning with 
$OfficialManufacturerDriver.

Due to these reports mostly centering on native-CMY dyesub models, my 
working hypothesis is that the problems are due to differences in the 
RGB->CMY conversion.

Along those lines, nearly all of the models that expect YMC data rely on 
single-channel mappings (ie R->C, G->M, B->Y) - Sometimes it's as simple 
as inverting the R/G/B values, but usually it's some form of fixed LUT.

So, to test my theory, what I'm ultimately trying to come up with is the 
"sum total LUT" that Gutenprint uses to transform the input data to the 
output data, and figure out how it's ultimately derived.  Unfortunately, 
Gutenprint's internal complexity is getting me twisted into mobius 
pretzels.

Here's a simplified version of what the dyesub driver does:

 0 setup_page_dimensions_resolutions_etc
 1 foreach ink_channels:
 2  stp_channel_add(channel)  # CMY in this case
 3 stp_color_init(256)        # ie 8bpp
 4 stp_set_float_parameter("AppGammaScale", 1.0)
 5 foreach input row:
 6  src = stp_color_get_row()
 7  dest = malloc()
 8  memcpy(dest, src)
 9 foreach printer_specific_curve  # optional
10  stp_set_curve_parameter(name, curve)
11 printer_header()
12 foreach printer_output_row
13   emit_formatted_output_row()
14 printer_footer()
15 profit

At (1-3), we set up the output channel mappings and initialize the color 
subsystem.  At this point, an LUT is created.  When dumped, it reports 
itself as RGB->RGB, and its mappings show that we map 8bpp RGB input 
into a linear 16bpp RGB working space.

(4) and (9-10) are interesting, leading to my first questions:

 * Does these calls have any effect, given that they both occur after 
   stp_color_init() and/or the stp_color_get_row() calls?
 * Are these applied curves absolute, replacing the existing curve 
   rather than applying on top of it?

At (6), we get an output row buffer that is comprised of 16bpp YMC data, 
which is downscaled linearly (/=257) in (13).  (This is a direct 
inversion of the input brightness correction LUT).  This leads to my big 
questions:

 * How/when is the RGB->YMC conversion done?
 * Is the output of stp_color_get_row() still linear 16bpp?
   * If no, how is it de-linearized?
   * If yes, are there just 256 discrete levels?

Trying to map the code flow out has given me quite a headache.  :)

Thanks,

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
High Springs, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.