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 <rlk@xxxxxxxxxxxx> 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 lpf@xxxxxxxxxxxx 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
