Re: [Gimp-developer] Missing from the roadmap

[Alexandre Prokoudine]

On Mon, Jan 11, 2016 at 9:43 PM, Elle Stone wrote:

> It would be nice if support for RGB working spaces other than sRGB, and also
> for "gamma" encodings other than the sRGB TRC, could be put on the roadmap
> for GIMP 3.2 as actual listed goals.

To the best of my knowledge, this [which version to put it into]
hasn't even been evaluated yet. That's mostly because both babl and
GEGL will need changes to address your request.

So yes, that coulld be put into 'Future', then get rescheduled once
changes land to babl and GEGL.

Alex
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Missing from the roadmap

[Michael Natterer]

On Tue, 2016-01-12 at 14:23 +0300, Alexandre Prokoudine wrote:
> On Mon, Jan 11, 2016 at 9:43 PM, Elle Stone wrote:
> 
> > It would be nice if support for RGB working spaces other than sRGB,
> > and also
> > for "gamma" encodings other than the sRGB TRC, could be put on the
> > roadmap
> > for GIMP 3.2 as actual listed goals.
> 
> To the best of my knowledge, this [which version to put it into]
> hasn't even been evaluated yet. That's mostly because both babl and
> GEGL will need changes to address your request.
> 
> So yes, that coulld be put into 'Future', then get rescheduled once
> changes land to babl and GEGL.

That seems like the right course of action.

--Mitch

___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Missing from the roadmap

[Alexandre Prokoudine]

On Wed, Jan 13, 2016 at 12:16 AM, Michael Natterer wrote:

>> So yes, that coulld be put into 'Future', then get rescheduled once
>> changes land to babl and GEGL.
>
> That seems like the right course of action.

Roadmap updated.

Alex
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Missing from the roadmap

[Partha Bagchi]

Hi Sven,

Elle has published a 2-part article on using GIMP for high bit depth
at Pat David's Pixl.us.

I am linking to part 1 for your convenience:

https://pixls.us/articles/users-guide-to-high-bit-depth-gimp-2-9-2-part-1/

Hope that helps.

Thanks,
Partha


On Tue, Jan 12, 2016 at 1:26 AM, Sven Claussner  wrote:
> Hi,
>
> just for a better understanding:
> - Is it for something that goes beyond assigning and converting to
> other color spaces? I think of native support of larger gamut color
> spaces than sRGB in Babl, GEGL and GIMP, am I right?
> - What exactly means 'supporting gamma-encodings other than the sRGB
> TRC' for intense GIMP users (artists and scientists)?
> - Is it something that happens only in GEGL and Babl or would also
> GIMP's code need to be touched?
>
> Greetings
>
> Sven
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives:   https://mail.gnome.org/archives/gimp-developer-list
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Missing from the roadmap

[Elle Stone]

On 01/12/2016 01:26 AM, Sven Claussner wrote:

Hi,

just for a better understanding:
- Is it for something that goes beyond assigning and converting to
other color spaces?


Yes.


I think of native support of larger gamut color
spaces than sRGB in Babl, GEGL and GIMP, am I right?


Yes. Different RGB working spaces have different RGB primaries 
(different XYZ locations for the color space's "reddest red, greenest 
green, and bluest blue" - 
http://ninedegreesbelow.com/photography/xyz-rgb.html#RGB).


Many of GIMP's editing operations make use of the color space's RGB 
primaries (for example, converting to black and white using Luma or 
Luminance, decomposing to LAB/LCH/YCbCr, the LCH blend modes, some of 
the noise reduction algorithms). These operations give wrong results for 
images in color spaces other than sRGB.


Many other editing operations *don't* make use of the color space 
primaries (for example, Levels, Curves, USM, Gaussian blur, scaling and 
other transforms). However, for radiometrically correct results, many of 
these "independent of the primaries" editing operations require being 
done on linearized RGB. So as explained below, in GIMP these operations 
also produce incorrect results for images other than sRGB images:



- What exactly means 'supporting gamma-encodings other than the sRGB
TRC'


Different RGB working spaces have different Tone Reproduction Curves 
(TRCs, http://ninedegreesbelow.com/photography/xyz-rgb.html#TRCs), and 
many RGB working spaces have TRCS that are more or less perceptually 
uniform (for example, gamma=2.2, gamma=1.8, and the sRGB TRC).


To produce radiometrically correct editing results, many GEGL and GIMP 
editing operations will request that the operation be done on linearized 
RGB.


Code in babl does the actual linearization and this babl code is 
hard-coded to linearize the sRGB TRC. So the only time the resulting 
"linearized" RGB values are actually linear is if the user really is 
editing an image that's encoded using the sRGB TRC.


sRGB is the only standardly-used RGB working space that uses the sRGB 
TRC. So results for images in other color spaces will be wrong.


There is code in GIMP that partially mitigates this problem by trying to 
make an RGB working space that has the user's RGB primaries and the sRGB 
or linear gamma TRC as required. But this code only works with images 
that were originally in RGB working spaces that already use the linear 
gamma TRC.



- Is it something that happens only in GEGL and Babl or would also
GIMP's code need to be touched?


As explained in the babl roadmap 
(https://git.gnome.org/browse/babl/tree/docs/roadmap.txt), currently 
babl is hard-coded only to support the sRGB primaries and the sRGB TRC.


To support other RGB working spaces, new babl formatters will need to be 
written.


Also new GEGL and GIMP code will need to be written that will call on 
the new babl formatters.


Elle
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Missing from the roadmap

[Elle Stone]

On 01/12/2016 01:26 AM, Sven Claussner wrote:

- What exactly means 'supporting gamma-encodings other than the sRGB
TRC' for intense GIMP users (artists and scientists)?


On the one hand, one goal for high bit depth GIMP is to make it easy for 
users to produce radiometrically correct editing results without having 
to know a lot (or anything) about color management, color science, and 
the mathematics of editing algorithms.


This important goal has been implemented pretty well (a handful of 
editing operations still use perceptually uniform RGB when they should 
use linearized RGB, and vice versa).


On the other hand, intense GIMP users - that is GIMP users who do have a 
working understanding of color management, color science, and the 
mathematics of editing algorithms - need control over their RGB working 
space primaries and TRC.


Control over the TRC:

The following bug report: 
https://bugzilla.gnome.org/show_bug.cgi?id=758001 provides a partial 
list of reasons why some users will want complete control over the TRC 
that's used to encode their RGB data. This bug report requests a GIMP 
GUI option to completely disable the babl code that linearizes the sRGB TRC.


A user option to disable the babl flips would go a long way towards 
making GIMP 2.10/3.0 much more friendly to intense users, and could 
probably be implemented more easily than providing full support for 
arbitrary user-chosen TRCs.


Control over the RGB primaries:

sRGB has a very small color gamut. Full support for arbitrary 
user-chosen RGB working spaces for babl/GEGL/GIMP might not happen very 
quickly, rather might take several years.


In the meantime, having at least one hard-coded wider gamut RGB working 
space made available through the GIMP UI would go a long way towards 
making GIMP 2.10/3.0 more friendly to intense users. Rec.2020 or ACEScg 
would both be excellent choices. Both of these color spaces are widely 
used by people working with VFX/CGI/Film, and both seem to produce 
better editing results than the print-based/Adobe-centric ProPhotoRGB:


http://colour-science.org/posts/about-rgb-colourspace-models-performance/
https://www.freelists.org/post/argyllcms/White-Point,45.

I would recommend Rec.2020 over ACEScg because ACEScg uses an imaginary 
primary.


Hard-coded RGB working spaces for GIMP would be nice to have:

Even if high bit depth GIMP already provided support for arbitrary 
user-chosen RGB working spaces, a selection of hard-coded built-in RGB 
working spaces is a solution to a problem that I believe Pippin 
mentioned awhile back: There are an awful lot of poorly-made RGB working 
space ICC profiles floating around out there. Providing users with a 
small selection of well-chosen and properly made built-in RGB working 
spaces seems to me to be a good thing to do. So providing at least one 
wider gamut RGB working space for GIMP 2.10/3.0 wouldn't be wasted 
coding effort.


Elle
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list