Hi, > 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. I hate to note that, but hopefully this will teach the one who applied that patch in request of someone else, to check patches more carefully before applying them. If you want to know who is ment here, read the ChangeLog. But I think you already guessed it... Salut, Sven
