On 10/14/2014 08:50 AM, Simon Budig wrote:
Elle Stone (ellestone@xxxxxxxxxxxxxxxxxxxx) wrote:
Are you planning on converting non-sRGB images to unbounded linear gamma
sRGB? Yes or no?
For pixel storage we will use whatever fits our needs, it does not make
sense at this point to specify this.
Whether or not the roadmap calls for converting non-sRGB images to
unbounded sRGB will determine what kind of code is written going forward.
In an ICC profile color-managed workflow, sRGB is just another RGB
working space, requiring no special treatment.
The babl roadmap "sRGB as PCS/fooRGB" is a proposed solution to
perceived problems. The problems for which "sRGB as PCS/fooRGB" might be
a solution are things like:
*Reducing computing overhead for 8-bit sRGB image editing.
*Accomodating legacy sRGB XCF files.
*Accomodating legacy "sRGB only" file formats.
Solving legacy and 8-bit sRGB overhead problems does not require
converting ICC profile color-managed images from fooRGB to unbounded sRGB.
If yes, are you intending that at least some editing will be done on the
image while it's encoded using sRGB primaries? Yes or no?
That totally depends on the editing-operation in question
When the user opens a color-managed fooRGB image, for which *specific*
editing operations will the image be converted to unbounded sRGB?
This isn't just an implementation detail. The answer to this question
will determine the path for writing code going forward. To restate the
question yet again:
Will all color-managed image editing be done using the user's chosen
primaries, with absolutely no conversions to unbounded sRGB for image
editing?
Or are the developers committing themselves to maintaining lists of
which operations should be done using fooRGB primaries and which should
be done using sRGB primaries?
With respect,
Elle Stone
_______________________________________________
gegl-developer-list mailing list
List address: gegl-developer-list@xxxxxxxxx
List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
