Hi Pippin and all, Thank you for your explanations. I just learned the term BoF :-))For me as a newbee in the LG community, I still have the feeling that this mailinglist is a good point to ask questions concerning data exchange and file formats between differnt LG apps. Handling of color in this context is one important aspect, but not the only one, I´m interested in.
I thought, that the OpenRaster format is defined by the LG community to allow the exchange of editable raster files between different LG Apps instead of using the PSD format? Is this a correct interpretation?
Is it correct that the .ora is the preferred format to exchange files e.g. between Krita and Gimp ?
Use cases for SVG instead of .ora?The current PSD format allows editable text and vetor layers for non destructive editing. Reading the Openraster documentation, i saw, that Vector and text layers are a whished from some persons, but there is currently no plan if and how it should be implemented.
This leads me to the questions, why not use SVG for such cases. SVG can handle both raster and vectorgraphics and is supported widely in the LG universe.
So my questions:Have you ever dicussed to use SVG als for Raster files to have the option to integrate editable vector and text layers into applications for handling raster files?
Regards Jan-Peter Am 04.06.2019 um 14:37 schrieb Øyvind Kolås:
On Mon, Jun 3, 2019 at 4:12 PM Jan-Peter Homann <hom...@colormanagement.de> wrote:3) GEGL and Color Pippin, did I understood you at LGM correct, that GEGL is able to use different ICC-profiles for chunks/nodes in the GEGL tree ? If yes, is it correct, that OpenRaster would not be an appropriate file format for such cases? or, If yes, do you provide an extension the the OpenRaster format? If not, this was probably a missunderstanding from my side... If yes, the complexity of interactions between colormanagement and blending modes will increase massively. Photoshop still avoids this complexity by allowing only one profile per document. If any new image with a differnt colorspace (e.g. CMYK instead of RGB) or different profile (e.g. sRGB instead of AdobeRGB) will be added to an document, all image colors will concerted to actual document colorspace.GEGL doesn't make use of OpenRaster, but there is nothing in the design of OpenRaster that is contrary to internal color management within the processing graph, PNG files (and OpenRaster extended with for instance TIFF or JPG or CMYK) can each independently hold the ICC information. The bottom-most/background layer in a sense becomes or dictates the document working space, since for compositing nodes the internal working space is a floating point associated-alpha variant of the pixel format accepted on the input pad, the data coming in on the secondary/"aux" pad gets converted to match the other, and the data is provided for further processing in the tree/graph in a space with primaries/ICC profile "inherited" from the background layer. In addition to this, GIMP goes further than GEGL in the compositing of its layers, the operations implementing layer modes permit specifying if they request data with no-TRC, the TRC from the ICC profile or a TRC with the float value 0.5 as middle gray. This permits maintaining the legacy results one gets with naive compositing of 8bit sRGB data for some layers as well as in the same document having more correct compositing without the gamma-related fringing doing it in sRGB would result in. This locally-in-graph handling of color space information also makes it possible to have multiple documents with different color spaces, as well as doing copy and paste between buffers with different model/precision/color space. /pippin P.S.: I encourage color focused participants of LGM to ask for a color-BoF for asking and getting answers to such questions as well as color specific notes sharing between projects at LGM, we used to have this in the past. Face to face communication is a lot more efficient use of time than mailinglists for, among others, dyslectic non-native english speakers - and in my experience color discussions seem particularly badly suited for mailinglists often deterioating into terminology related confusion, misunderstandings, and flames.
-- Homann colormanagement tel: +49 30 611 075 18 Jan-Peter Homann mob: +49 171 54 70 358 Herzbergstr. 55 www.colormanagement.de 10365 Berlin mailto:hom...@colormanagement.de
<<attachment: homann.vcf>>
_______________________________________________ CREATE mailing list CREATE@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/create
