On Sun, Nov 29, 2020 at 2:43 PM JonnyRobbie via gegl-developer-list <gegl-developer-list@xxxxxxxxx> wrote: > > I still feel like I haven't gotten the hang on it. Your expectations of gegl:convert-space 's behavior is mostly right, it was the code that wasn't ready but a rather good draft had been written and presumed to work when it compiled without manual testing. Please pull and try again, for a bonus you can also pull in babl, for fixes to CMYK profile handling, with both babl and GEGL from master gegl:convert-space with an ICC profile is now sufficient for converting an RGB to that CMYK profile, or similarly using a given RGB profile for CMYK inputs. > First of all - if I don't specify bitdepth and fp in the gegl:tiff-save, gegl seems to convert the image to 32b float. This is expected behavior, the specified output formats for gegl:convert-space was "RGBA float", and now is "RGBA float", "YA float" or "CMYKA float" depending on the type of color space. A GEGL graph doesn't have a global concept of u8 vs u16 vs half vs float, so just like gaussian-blur we need to increase precision from - for example u8 - to avoid losing some fidelity that is lost in any u8 <-> u8 color conversion. There are a few ops, like gegl:crop, that do not tend to "upgrade" the precision like this. In GIMP results gets merged back down to the documents precision when changes are stored in layers. gegl:convert space is also not clipping the resulting colors to 0.0-1.0 range following it with an gegl:rgb-clip would do so though. /pippin _______________________________________________ gegl-developer-list mailing list List address: gegl-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
