On Mon, 3 Jul 2017 18:55:42 +0200
Laslo Hunhold <dev_AT_frign.de> wrote:
> On Mon, 3 Jul 2017 18:47:37 +0200
> Mattias Andrée <maandree_AT_kth.se> wrote:
>
> Dear Mattias,
>
> > Perhaps farbfeld should specify that it should use linear sRGB, right
> > now it specifies sRGB, which implies non-linear. It wouldn't make
> > the format less complicated in my opinion, but it would be easier to
> > implemented editing tools.
>
> It would make it easier to implement the tools, however, this would on
> the other hand force everybody trying to display farbfeld images to
> make the transformations back to non-linear sRGB.
Yes. However, if this is not done, the error is probably less than if
multiple edits have been made to the image without considering this.
> As you already explained pretty well, the non-linear gamma curve is
> there for a reason.
>
> > The problem with treating non-linear colour models as linear is that
> > the error accumulate. Whilst you may not notice the error after one
> > edit unless you compare the image to the correct one, it will be
> > noticeable if you apply multiple change.
>
> This is correct, but only applies to cases where we need "exact"
> transformations. Every non-integer arithmetic operation has the
> potential to be erroneous. Given we have 16 bits per channel, the
> accumulated error would be invisble in most cases, even for long
> pipelines (if you don't do anything crazy).
>
> > 50 % bright in the linear model is at 0.50, but at 0.74 in the
> > non-linear model. The difference is almost 50 %, the difference is
> > larger at darker colours.
>
> When was the last time you needed to brighten up your picture by
> "exactly factor 2"? Most of the time, people open GIMP and move the
> slider until the brightness suits their taste.
That was just an example to illustrate how manipulations should be
applies. And indeed it is not common that you need exact changes.
If you need exact colours you probably don't want to use farbfeld
at all because it is restricted to colours in the sRGB gamut.
To avoid the problem with the transfer function, it is probably
enough (since farbfeld uses 16-bit values) to add a tool applies
the inverse transfer function and a tool that applies the transfer
function. That way, the editing tools can be as simply as they are
today, but you can get rather exact results if you need it.
>
> With best regards
>
> Laslo Hunhold
>
Received on Mon Jul 03 2017 - 19:11:46 CEST