On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone
<ellestone ninedegreesbelow com> wrote:
> On 10/15/2014 01:46 PM, Simon Budig wrote:
> If I understand them correctly, Michael Henning and Jon Norby are saying
> that the criteria is something along the lines of: "For RGB editing
> operations, use UserRGB primaries *unless* there's a really, really good
> reason why only sRGB primaries will work."
>
> Is there in fact general agreement among the devs that the criteria for
> deciding when to use sRGB primaries instead of UserRGB primaries is
> approximately as follows?
Once we have the vocabulary to also describe this aspect of the
pixelformats used by operations, the first thing we should do is to
annotate all the operations which are broken when done with sRGB
primaries, then we will be able to continue refactoring, profiling and
optimizing; without breaking existing functionality/rendering. Not
only in terms of making more operations request directly userRGB, but
also doing things like make some linear operations accept any of
userRGB or bablRGB (or other linear RGB); and creating output buffers
in the same format – to avoid unnecessary conversions in such cases.
Using a fixed linear RGB format instead of userRGB is what for some
operations will provide the consistent results for the same property
values / slider positions. Knowing which operations this is important
for is easier to determine when we have code providing the vocabulary
in babl. The further along on the roadmap, more of the road will have
to be laid/determined as we walk it.