On Sun, Nov 16, 2014 at 9:01 PM, Elle Stone <[email protected]> wrote: > Do you understand that when I say that Multiply is a chromaticity-dependent > editing operation, I don't just mean the Multiply layer blend mode? that in > fact *all* editing operations that use multiplication or division are > chromaticity dependent, regardless of whether the colors are *in* gamut or > *out* of gamut with respect to the very small bounded sRGB color gamut? > > The exception to "all", of course, is when multiplying or dividing by black, > gray, or white.
Yes I do understand that – The babl roadmap being incomplete/leaving room for interpretation is on purpose – what is stated there is the minimum roadmap bringing us towards a situation where such details makes sense to decide upon. Some operations we might change to not be chromaticity dependent in this way (for instance using CIE Lab or Lch) but for most of them the change will be using a babl-format specifiers like "target:RGBA" and "target:R'G'B'" instead of un-prefixed format specifiers like now, which in the future will be synonyms for "sRGB:RGBA" etc. > Somewhat switching gears, the revised babl roadmap > (https://git.gnome.org/browse/babl/tree/docs/roadmap.txt) says: The plan in roadmap hasn't really changed since mid-april[1], revisions to the file has been integrating various bits lost in the mailinglist threads. The last revisions was to add what has been stated before in gimp-developer about single-precision floating point and accumulated rounding errors – since the issue was brought up here. > "Once a format has been resolved using babl_format(babl, "bar:RGBA float") > the returned pointer would refer to the babl context that looked up "bar"'s > definition of bar. This . . . allows rigging up a situation where the user > has control over the RGB space used for chromaticity dependent operations." > > In light of the revised roadmap and the above list of chromaticity dependent > editing operations, I have two more questions. Again, I'm trying to > establish common ground for communication, or at least clarify where we > disagree. > > 1. Do you agree or disagree that for *all* chromaticity dependent editing > operations, the *user* should be in control of which RGB chromaticities are > used to perform the operation? That is the point of adding more, and named, RGB families to babl. Chromaticity dependent operations are the operations where we would use userRGB instead of bablRGB – effectively it being the way for the developer to say that for this operation the users chosen format should be used. using user:Y user:Y' user:R'G'B' and user:RGB would be different ways the op developer can request pixel formats based on this user choice; when the op developer knows it should (or should not) be linear of perceptual data. But also note that while in GIMPs use of babl/GEGL, there might only be one such user family of pixel formats controllable in one location of the UI, in the general flow based computing model of GEGL one might expect a single configured processing graph to have multiple userRGBs for photos coming from different sources. > 2. Do you agree or disagree that for chromaticity *in*depedent editing > operations (for example, and assuming linearized RGB: adding, scaling, > gaussian blur, etc), the same results (same XYZ values) are obtained whether > the operation is done in the user's chosen RGB working space or in unbounded > sRGB? I do; and if there wasn't any chromaticity dependent operations – a single "RGB family" like bablRGB would be sufficient – You convinced us to abandon that plan in april. If a GEGL graph contains multiple different userRGBs source buffers, chromaticity independent compositing operations compositing two buffers with different RGB chromaticities need to be converted to the same linear RGB. Initially this will be bablRGB; later – depending on profiling and time for doing it – we might end up making such compositing produce output in the same RGB family as the input buffer and convert the aux buffer to the same. 1: the only change in plans since then (and that changed occured before roadmap.txt was started), was abandoning the plan to do conversions between bablRGB and userRGBs in babl using LCMS2; and instead do those conversions directly ourselves in babl; a change without impact on how babl will be used by GEGL (and GIMP). /pippin _______________________________________________ gimp-user-list mailing list List address: [email protected] List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
