I will be sending Sven the 3.0.8 patches shortly.

I think I know why Michael got his solid black output, and it had
nothing (really) to do with the bug fixes I did for 3.0.7.  The
problem was that someone ripped out the calc_rgb_to_hsv and
calc_hsv_to_rgb functions I put in print-util and replaced them with
gimp_calc_rgb_to_hsv4 without taking a closer look at what's going
on.  My functions operated on unsigned shorts (16 bits), while the
libgimp versions operate on unsigned chars (8 bit).  So whenever
anyone used a saturation other than 1.0, the top 8 bits were
effectively stripped off the rgb values, making them close to zero
(and hence the cmy values close to 1).  I'm surprised that a lot more
people didn't stumble over this.

There are good reasons for the print code to be 16 bit -- 8 bit output
resolution is insufficient for printing when you take into account the
gamma that is required to get decent output.  The highlight tones
(light areas) are compressed into a very narrow range, and in some
cases even 16 bits of resolution results in two input levels (between
0 and 255) mapping into identical output levels.  Please don't be too
quick to gratuitously change code like that.

Robert Krawitz <[EMAIL PROTECTED]>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Reply via email to