[CREATE] Some questions about OpenRaster Format, Color and SVG

[Jan-Peter Homann]

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
> <homann at 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:homann at colormanagement.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: homann.vcf
Type: text/x-vcard
Size: 264 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/create/attachments/20190604/cb429974/attachment.vcf>