Re: [dev] Problems with farbfeld image editing tools
On Mon, 3 Jul 2017 19:11:46 +0200 Mattias Andréewrote: > On Mon, 3 Jul 2017 18:55:42 +0200 > Laslo Hunhold wrote: > > > On Mon, 3 Jul 2017 18:47:37 +0200 > > Mattias Andrée 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. I think some tools must still be aware of sRGB's non-linearity. For example, if you make a tool that draws a gradient, you probably want the colours in the gradient to increase linearly, so you have to be that the colour model is not linear. > > > > > With best regards > > > > Laslo Hunhold > > > pgpaWZSBBMnbR.pgp Description: OpenPGP digital signature
Re: [dev] Problems with farbfeld image editing tools
On Mon, 3 Jul 2017 18:55:42 +0200 Laslo Hunholdwrote: > On Mon, 3 Jul 2017 18:47:37 +0200 > Mattias Andrée 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 > pgpxA9_5kvQ5H.pgp Description: OpenPGP digital signature
Re: [dev] Problems with farbfeld image editing tools
On Mon, 3 Jul 2017 18:47:37 +0200 Mattias Andréewrote: 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. 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. With best regards Laslo Hunhold -- Laslo Hunhold
Re: [dev] Problems with farbfeld image editing tools
On Mon, 3 Jul 2017 18:25:23 +0200 Laslo Hunholdwrote: > On Mon, 3 Jul 2017 17:28:29 +0200 > Mattias Andrée wrote: > > Hey Mattias, > > > Because if the limited number of values that can be stored in an > > 8-bit integer and because humans don't notices small differences > > between dark colours as well as small differences in bright > > colours, sRGB encodes colours non-linearly so there are more > > bright colours and fewer dark colours. > > yes, this is correct. > > > However, looking at image editing tools for farbfeld I've found > > that the tools do not take this into account. For example, making > > a colour twice a bright, is not as simple as multiply the RGB > > values with 2 > > It is if you have linear RGB. If you make the proper transformation > from sRGB to linear sRGB, it is perfectly valid. > > > , rather the algorithm that shall be used is > > > > x = F(2 ⋅ F⁻¹(x₀)) > > > > where F is sRGB's transfer function > > > >⎧ -F(-t) if t < 0 > > F(t) = ⎨ 12.92 tif 0 ≤ t ≤ 0.0031306684425217108 [*] > >⎩ 1.055 t↑(1/2.4) - 0.055 otherwise > > > > [*] Approximate value. You will often find the value > > 0.0031308 here, but this value is less accurate and > > only good enough when working with 8-bit integers. > > How do you expect anyone to understand this? It's better to just work > with linear sRGB. The transfer function is the inverse of the > companding function and it honestly does not look very nice. The > companding function gives more insight in how sRGB works and does not > hide it behind closed doors. > > sRGB is a pretty complex matter in my opinion. We don't just have an > exponential gamma function, but one that is companded differently below > a certain treshold. However, it's not nearly as complicated as general > colour theory. > If we have nonlinear sRGB-values V (where V is one of R,G,B), we can > make the conversion to linear sRGB (v where v is one of r,g,b) via > > ⎧ V / 12.92V <= 0.04045 > v = ⎨ > ⎩ [(V + 0.055) / 1.055]^2.4else > > Credit goes to Bruce Lindbloom[0] for creating this awesome collection > of transformation formulae. > > After all though, if you mistake linear and nonlinear RGB, you most > likely won't see the difference anyway. In 99% of the cases, the tools > work with an immediate visual feedback. > > With best regards > > Laslo Hunhold > > [0]: http://www.brucelindbloom.com/ > 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. 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. 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. pgphwMPa_GaBX.pgp Description: OpenPGP digital signature
Re: [dev] Problems with farbfeld image editing tools
On Mon, 3 Jul 2017 17:28:29 +0200 Mattias Andréewrote: Hey Mattias, > Because if the limited number of values that can be stored in an > 8-bit integer and because humans don't notices small differences > between dark colours as well as small differences in bright > colours, sRGB encodes colours non-linearly so there are more > bright colours and fewer dark colours. yes, this is correct. > However, looking at image editing tools for farbfeld I've found > that the tools do not take this into account. For example, making > a colour twice a bright, is not as simple as multiply the RGB > values with 2 It is if you have linear RGB. If you make the proper transformation from sRGB to linear sRGB, it is perfectly valid. > , rather the algorithm that shall be used is > > x = F(2 ⋅ F⁻¹(x₀)) > > where F is sRGB's transfer function > > ⎧ -F(-t) if t < 0 > F(t) = ⎨ 12.92 tif 0 ≤ t ≤ 0.0031306684425217108 [*] > ⎩ 1.055 t↑(1/2.4) - 0.055 otherwise > > [*] Approximate value. You will often find the value > 0.0031308 here, but this value is less accurate and > only good enough when working with 8-bit integers. How do you expect anyone to understand this? It's better to just work with linear sRGB. The transfer function is the inverse of the companding function and it honestly does not look very nice. The companding function gives more insight in how sRGB works and does not hide it behind closed doors. sRGB is a pretty complex matter in my opinion. We don't just have an exponential gamma function, but one that is companded differently below a certain treshold. However, it's not nearly as complicated as general colour theory. If we have nonlinear sRGB-values V (where V is one of R,G,B), we can make the conversion to linear sRGB (v where v is one of r,g,b) via ⎧ V / 12.92V <= 0.04045 v = ⎨ ⎩ [(V + 0.055) / 1.055]^2.4else Credit goes to Bruce Lindbloom[0] for creating this awesome collection of transformation formulae. After all though, if you mistake linear and nonlinear RGB, you most likely won't see the difference anyway. In 99% of the cases, the tools work with an immediate visual feedback. With best regards Laslo Hunhold [0]: http://www.brucelindbloom.com/ -- Laslo Hunhold
[dev] Problems with farbfeld image editing tools
Because if the limited number of values that can be stored in an 8-bit integer and because humans don't notices small differences between dark colours as well as small differences in bright colours, sRGB encodes colours non-linearly so there are more bright colours and fewer dark colours. However, looking at image editing tools for farbfeld I've found that the tools do not take this into account. For example, making a colour twice a bright, is not as simple as multiply the RGB values with 2, rather the algorithm that shall be used is x = F(2 ⋅ F⁻¹(x₀)) where F is sRGB's transfer function ⎧ -F(-t) if t < 0 F(t) = ⎨ 12.92 tif 0 ≤ t ≤ 0.0031306684425217108 [*] ⎩ 1.055 t↑(1/2.4) - 0.055 otherwise [*] Approximate value. You will often find the value 0.0031308 here, but this value is less accurate and only good enough when working with 8-bit integers. pgps98aZmwvZH.pgp Description: OpenPGP digital signature