El jue, 17-04-2014 a las 16:48 +0200, Nicolas Robidoux escribió: > Opinion: > > Using, internally, a reference unbounded color space (or two: one linear, > one perceptual, with, possibly low precision shadows for speed), and > converting in and out of it when an image is imported or exported is a sane > choice. It's still not clear (at least for me) what is the impact or the unbounded color values in processing. I'm not pretending I have all the answers, so I'm proposing to discuss it. Elle and I brought a couple of examples where those unbounded values introduce problems, and we didn't get direct answers about them. I think it's not a sane choice pretending that all the cases that don't fit the model are just corner cases. It's quite contradictory to be extremely worried to keep the appearance and behavior of legacy files, and at the same time throw away valid cases of high-end professional editing, labeling them as "corner cases". > Deviations from the "standard internal color space(s)" should be motivated > by the operation being performed, not by the color spaces of the initial > and final results (which may or may not belong to the same ones in any > case). > There are, no doubt, situations in which alternate internal color spaces > could give better results. But catering to these corner cases is likely to > cause endless headaches for developers and bring no benefit whatsoever to > 99.999% of users. It would be interesting to discuss if those cases are really corner cases. Pulling mattes from green/blue screen shots is really common in VFX, and high end cameras usually have way more color latitude than sRGB, what means that an important part of the gamut needed to pull those mattes would end in the out-of-gamut, hence "unbounded" realm. We're not talking about details invisible to the eye as in Elle's yellow cone flower example. Please, don't take this as an attack to the project. I'm just sharing my concerns as a commited heavy user of GIMP and free software. In the end I'll respect your decisions even if I don't agree with them, because you guys are doing all the heavy lifting. Gez. _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
