On Thu, Oct 9, 2014 at 7:22 PM, Elle Stone <ellestone@xxxxxxxxxxxxxxxxxxxx> wrote: > My assumption was that "sRGB as PCS" only made sense in the context of using > unbounded sRGB as a universal working space. > > If "sRGB as PCS" means that unbounded linear gamma sRGB is used to convert > from RGB to XYZ to LAB, for example, then I'm not sure when "sRGB as PCS" > would be used. For example, for converting to LAB, use the user-chosen > primaries (colorants) to convert to XYZ and then to LAB. See below. >> Ie, babl will support your suggestion (user-chosen primaries with >> either linear or sRGB TRC) in addition to sRGB, instead of replacing >> sRGB. > > > Does "in addition to sRGB" mean duplicate code files side by side, one set > of files hard-coded for just sRGB images and one using Y and XYZ values > retrieved from the user's chosen primaries? For example, the babl code that > converts from color to Luminance for painting on a mask would be duplicated, > once for sRGB and once generalized? To some degree, yes. We don't need to recreate every single transformation. For example, when converting from some arbitrary RGB color space to luminance, we can chain the conversions: first, one conversion from the user-specified RGB space to linear sRGB, and then from linear sRGB to luminance. If that's too slow, we also have the option of defining "fast paths" that convert directly between two color spaces, but the core of babl always converts to linear sRGB as an intermediate. This is what we mean when we say "sRGB as PCS": all of the color formats are defined in terms of linear sRGB, so if a given transformation hasn't been coded specifically, we can use linear sRGB as an intermediate. Also, some portions of sRGB will probably share code with the generic RGB code. But, the important point is that we want sRGB to still exist within babl as a usable, built-in format. >> >>> Adobe-centric advice implies that color gamut is the only consideration >>> when >>> choosing an RGB working space. Adobe has hard-coded ProPhotoRGB primaries >>> into their raw processing software. It is distressing to see GIMP follow >>> Adobe's lead by writing code on the assumption that the sRGB primaries >>> are >>> suitable for editing all images. >> >> >> I'll repeat that the sRGB primaries won't be the only supported >> working space. You talked us out of that idea a long time ago. > > > Oh. I didn't realize that. Maybe we weren't too clear. :P > The temperature change code produces very pleasing results for sRGB images, > much nicer than another editor that I tried. Based on eyedroppering and > comparing to spreadsheet calculations, the colors aren't colorimetrically > correct and maybe they never were intended to be. On the other hand, I only > checked Bradford adaptation and I'm not 110% certain I handled all the > matrix math correctly. > > The current code uses hard-coded coefficients based on sRGB primaries and > produces obviously wrong results for non-sRGB images. Bradford/CAT02 etc > chromatic adaptation code would seem to be a logical generalized > replacement. > > This article demonstrates using CAT02 to do color temperature corrections: > http://nbviewer.ipython.org/gist/kelsolaar/7098c6709c59b9afb018 > The article uses the D65 sRGB color space, not the D50-adapted sRGB ICC > profile color space, but it illustrates the math nicely. Okay, we should probably look at that then. From, Mike Henning _______________________________________________ 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
