On Sun, Oct 5, 2014 at 5:16 PM, Elle Stone <ellestone@xxxxxxxxxxxxxxxxxxxx> wrote: > On 10/04/2014 11:59 AM, Øyvind Kolås wrote: >> >> On Sat, Oct 4, 2014 at 2:46 PM, Elle Stone >> <ellestone@xxxxxxxxxxxxxxxxxxxx> wrote: >>> >>> Based on the groundless premise that editing operations should > > produce the >>> >>> same results when performed on the same colorimetric colors, .. >> >> >> No; > > > I'm not sure what you are saying "No" to. Here are excerpts from previous > posts that you've made talking about the matter: > http://article.gmane.org/gmane.comp.video.gimp.devel/19916 I am saying no to it being groundless premise, It is a desirable interaction goal. It is the same desire that makes sure that things like image resampling and blurring should always happen with _associcated_alpha_ and linear TRC. Instead of letting the user configure a working space where scaling or blurring behaves in ways not resembling physics. The architectural implementation of that desire is tagging of all buffers explicitly with their color space, associated alpha state, data type etc. Each operation tells GEGL both what type of data it wants to read as well as what type of data it wants to write in the "prepare" stage for the op, which happens before any data is being processed. With what has been proposed as a solution for ops that need to use a target/working RGB space is that the operation would ask for a special symbolic babl format or similar; and GEGL/babl does the rest behind the scenes. Most current named BablFormats are immutable - in the same ways ICC profiles are treated as immutable. Changing the meaning of "R'G'B'A u8" or "Y'CbCr u8" and similar will break color management for operations providing integration with various image loaders/video codecs/webcam/GUI that already exist. >> My stance is that the sliders on an >> operations should be predictable and always do the same thing for the >> colorimetrically absolute same color (relative colorimetric likely makes more sense; or perhaps just colorimetric - though thats a detail). > http://markmail.org/message/n6ttql3ajtjbe767 >> >> GEGLs image processing is intended to all operate in device independent >> color spaces, no matter which camera you took a picture with >> gaussian blurs, color adjustments etc, should behave the same. > > >> No; but same parameters for same input colors producing same results >> is considered desirable behavior. Predictable interfaces are nice >> interfaces. > > > In a properly color managed image editor, the way for a user to get > predictable editing results is to set up a consistent workflow based on the > RGB working spaces that the user finds appropriate for the tasks at hand. I don't think a medium high-end user of GIMP should _need_ to be concerned about working spaces; we should strive to make a system that behaves well by default. > Until GIMP is properly color managed, the only users who might find GIMP > editing results predictable are users who already only edit their images in > the sRGB color space. GEGL strives to bring linear light editing all the places it makes sense; this will hopefully be a better experience than 8bpc sRGB. "properly color managed" is not one single thing, sure GIMP/GEGL is not there yet, but for a GIMP 2.10 release it is good enough. (2.10s stated goal is being to be able to do what 2.8 does; but with GEGL inside - the higher bitdepths and such are bonus.). One could also claim that a system that converts everything to a single working space and passes pixels untagged through is "weaker" color managed than the plan that has been outlined for GEGL. You've already been invited, and I invite you again to spend some time with the rest of the GIMP team and others with interest in color, photography and graphics in Toronto, end of april next year for the next Libre Graphics Meeting. /Ø _______________________________________________ gegl-developer-list mailing list List address: gegl-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
