On Wed, Nov 19, 2014 at 9:28 PM, Elle Stone <ellestone@xxxxxxxxxxxxxxxxxxxx> wrote: >> On Wed, Nov 19, 2014 at 7:31 PM, Elle Stone >> <ellestone@xxxxxxxxxxxxxxxxxxxx> wrote a lot of text that has been >> trimmed away... > > Hmm. > > I worked hard to explain why even for chomaticitiy independent editing > operations the RGB data shouldn't be converted to unbounded sRGB. > > You dismissed my efforts with "Elle Stone wrote a lot of text that has been > trimmed away..." I think it is too early to productively discuss implementation details in GEGL, and therefore choose to focus on things that are *not* implementation details. Thankfully you no longer seem to disagree with the general direction of the babl roadmap as can be seen in your reference to how the architecture of babl/GEGL goes beyond traditional ICC RGB editing, encompasses HDR. There is much work to be done in babl – by someone; not neccesarily me – before it is possible to experiment with different approaches. When we can profile running code, see what the CPU is busy doing most of the time and then spend time refactoring unneccesary conversions away. I have even speculated and pointed out likely complications for some of the chromaticity independent operations when *different* user:RGBs are to be composited. To repeat an earlier remark on one of the other points, there is no lists to maintain of which operations operate with what representation – this is local to the ops. Each individual operation within its own code specifies the data representation of input and output data in its own implementation. /pippin _______________________________________________ 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
