Re: [Gimp-developer] [Gegl-developer] babl roadmap
Am Mittwoch, 15. Oktober 2014, 15:37:01 schrieb Elle Stone: [...] > The guiding principle should be that except in these carefully bracketed > and clearly identified cases, the *user* controls the RGB working space, > and all RGB editing operations should use the user's chosen primaries. It seems this is the central point. The choice of bablRGB (or linear sRGB or linear Rec709) is merely an implementation detail and only works as the base transformation matrices are calculated on. Think of it as bablXYZ. It's the common ground babl does its color transformations on, just like ICC uses XYZ. This however is not the working space used in the gegl tree and therefore in GIMP. Just as applications using ICC internally don't work on XYZ data. The reason why babl uses bablRGB instead of XYZ is just so that the common case of using sRGB data that is coming from the outside world (pippin gave the example of text rendered by cairo) can be used directly and doesn't need a conversion step. Code making use of the babl functions is free to keep every imported buffer in its native color space (probably linearized) and the system will make sure that the data is treated the right way when a conversion is required (for example when merging layers -- which format would win is probably a point to be discussed later). At least that's how I understood the situation. > Kind regards, > Elle Stone Tobias signature.asc Description: This is a digitally signed message part. ___ 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] [Gegl-developer] babl roadmap
On 10/15/2014 01:58 PM, Michael Henning wrote: Yes, the majority of operations will operate in myfavoriteRGB space, but you seem to be operating under the premise that absolutely *no* filters can possibly exist that require a specific color space to function properly. This isn't the case. Actually, I did go through the code base as thoroughly as possible, and I did identify various editing operations that depend on the data being in specific color spaces (not always D50-adapted sRGB). See http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html Take, for example, the color blindness simulation in gimp. This filter tries to simulate color blindness so that artists can create images that look good to people who are color blind. An operation like this should not change based on which working space you choose to edit in; it must always try to be as faithful to colorblindness as possible. For an operation like this, being able to specify the working space on the developer's side is a must. Otherwise, it can't work properly. This is one of the operations that I identified. I also noted that ALL such operations should be clearly identified as such in the UI. While operations like that might not be too common, it should still be physically possible to create them. Before you say "okay, so a proper icc color managed editor will convert between icc profiles, what's the big deal?", realize this: babl is exactly the mechanism that we are using to make that happen. These "background conversions" that you seem to hate so passionately The background conversions that I was objecting to two years ago convert between perceptually uniform and linear gamma RGB data, using the sRGB TRC as a stand-in for true perceptual uniformity. Those are the babl/babl/base/util.h TRC flips. I do recognize (now, but not two years ago) the point of the TRC flips. The point is to be able to flip instantly between linear gamma and perceptually uniform RGB. See http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html#best-solution In my working copies of babl/GEGL/GIMP I have the babl TRC flips disabled because the ways in which the user can choose perceptual vs linear encoding are not transparent and also subject to change. But I'm looking forward to having the UI make it easy for the user to be able to switch at will. Assuming the devs will allow the user the freedom to make such choices. are exactly the same conversions that you already admitted were necessary when copying and pasting between images. Just because conversions shouldn't be common does not mean they should be impossible, or removed altogether. I've already said elsewhere in this thread that how you get from RGB to XYZ/LAB/etc is really irrelevant as long as the end result is correct. The same thing applies to conversions from one set of RGB primaries to another set of RGB primaries. Also, given a bug in current LCMS conversions between RGB matrix profiles, I would rather babl did the conversions. See http://sourceforge.net/p/lcms/mailman/message/32834352/ But even when that particular LCMS bug is fixed, there doesn't seem to be any advantage to calling on LCMS to do simple matrix conversions. The only real drawback to all of the above is I can't see any way a GIMP user can edit their images in an RGB *LUT* color space. From my own point of view, that would never be a concern. But it should be noted that babl/GEGL/GIMP does seem to have this one requirement. It should be noted that such cases as the colorblind filter and the old device-based code should be treated as explicit exceptions, labelled in the UI. The guiding principle should be that except in these carefully bracketed and clearly identified cases, the *user* controls the RGB working space, and all RGB editing operations should use the user's chosen primaries. Kind regards, Elle Stone ___ 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] [Gegl-developer] babl roadmap
+ > 1 On Oct 14, 2014, at 9:06 PM, scl wrote: > Hi, > > I fully agree with Jehan and think it's essential > in a healthy software development process to scrutinize > and review things. Especially the whole color management > stuff is a topic that is not so clear to many of us and > - with all my respect to Pippin - depending on a > single expert's opinion is a risk in every project. > It's natural for this topic that it is also academic. > Academic work is the foundation for many things in the > computer world, may the hands-on-people like it or not. > Perhaps some other color management experts could join in > and share their knowledge? > One thing could be improved from my point of view: the > discussion is spread over the two lists gimp-developer and > gegl-developer. As it is all mainly BABL- and GEGL-related > it would be more helpful if the discussion took place on > a single list. I propose the GEGL-developer list, because > this catches both the GEGL-only devs as well as the GIMP > devs. > > Kind regards > > 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] [Gegl-developer] babl roadmap
Yes, the majority of operations will operate in myfavoriteRGB space,
but you seem to be operating under the premise that absolutely *no*
filters can possibly exist that require a specific color space to
function properly. This isn't the case.
Take, for example, the color blindness simulation in gimp. This filter
tries to simulate color blindness so that artists can create images
that look good to people who are color blind. An operation like this
should not change based on which working space you choose to edit in;
it must always try to be as faithful to colorblindness as possible.
For an operation like this, being able to specify the working space on
the developer's side is a must. Otherwise, it can't work properly.
While operations like that might not be too common, it should still be
physically possible to create them. Before you say "okay, so a proper
icc color managed editor will convert between icc profiles, what's the
big deal?", realize this: babl is exactly the mechanism that we are
using to make that happen. These "background conversions" that you
seem to hate so passionately are exactly the same conversions that you
already admitted were necessary when copying and pasting between
images. Just because conversions shouldn't be common does not mean
they should be impossible, or removed altogether.
-- Mike Henning
On Wed, Oct 15, 2014 at 1:27 PM, Jon Nordby wrote:
>
> On Oct 15, 2014 4:19 PM, "Elle Stone"
> wrote:
>>
>> On 10/15/2014 08:30 AM, Øyvind Kolås wrote:
>>
>>> On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone wrote:
>>
>
> Hi, I fear you two are talking past eachother.
>
>> I will ask again:
>>
>> For which specific RGB editing operations do you plan to convert the image
>> from fooRGB to unbounded sRGB before performing the operation?
>>
>> Either the answer is "None. For color-managed fooRGB images, all RGB
>> operations will be done on data encoded using fooRGB primaries."
>
> The answer is (to best of my understanding): Typically none. When chosing to
> work in myfavoriteRGB for one "scene" (can be a GIMP document), all
> operations which specify that they work in any RGB color space, using
> babl_format("scene:RGBA float") will operate on myfavoriteRGB data. So if
> there is myfavoriteRGB image as input, and that also is the desired output,
> there will be zero data conversions.
>
> Supporting any RGB spaces should be the case for the vast majority of
> operations dealing with RGB data, including multiply/invert and similar.
> With respect to the roadmap, these operations are *currently wrongly tagged*
> to only work in unbounded sRGB. This is only because we don't have the new
> architecture implemented yet!
>
> I say 'typically' because if some operation *does* specify babl_format("RGBA
> float") to indicate that it just works with unbounded sRGB, a conversion
> will happen. This should of course *only be used in some cases*, when it
> actually just works with the specific format. I can't immediably think of
> any usecase for this, but there probably are some.
>
> I hope this addresses some of your concerns,
> Regards Jon
>
>
> ___
> gegl-developer-list mailing list
> List address:gegl-developer-l...@gnome.org
> List membership: https://mail.gnome.org/mailman/listinfo/gegl-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] [Gegl-developer] babl roadmap
Elle Stone (ellest...@ninedegreesbelow.com) wrote: > On 10/15/2014 08:30 AM, Øyvind Kolås wrote: > >On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone > >>When the user opens a color-managed fooRGB image, for which *specific* > >>editing operations will the image be converted to unbounded sRGB? > > > > >If the user is putting a text-layer, which has been rendered using > >cairo and is in 8bit sRGB premultiplied alpha. The compositing of this > >with preceding data in the layer stack the babl-format of the output > >buffer of the over/normal compositing operation, as well as the data > >fetched from both buffer inputs - would likely be RaGaBaA float - if > >the two linear inputs differ. > > I'm not sure why your text-layer stack example is relevant to my very direct > and still unanswered question. As you very well know we don't *have* the specific list of editing operations you ask for. I don't know why you keep repeating the question. You seem to think that not getting an answer to that question proves a point, but I definitely have no idea what the point is. What would be the benefit of having such a list? If the implementor of an operation thinks, that an operation needs to work in unbounded bablRGB then it will request bablRGB input and gegl/babl will do its work to provide that. An example *could* be an operation that does change the "warmth" of an image by simulating lighting by a different illuminant. The operation could request bablRGB input data, convert that to XYZ internally, do the shift, convert back to bablRGB and provide that as output. But then the author might be better off with requesting the data in XYZ directly, saving him from the work of doing the bablRGB to XYZ conversion: Gegl/Babl does that for him. Both ways are fine, Gegl/Babl can do this today. It is up to the author to choose and it will be *completely* transparent to the user of the operation. This is completely independent from how the image pixels are stored in memory, even when they are stored with a different set of RGB primaries. Gegl/babl in that case will know how to transform the stored pixels into bablRGB the operation requests, and they'll know what to do with the output. The text example from pippin is supposed to illustrate that Gegl in real world situations has to deal with external sources which are beyond the control of Gimp. And Gegl/Babl provide the facilities to deal with that. > >At all points we know the CIE Lab or XYZ coordinates of all involved > >pixels > > You don't "know" the XYZ coordinates until you actually convert from fooRGB > to XYZ. Likewise with CIELAB. So it's not clear what the above sentence > really means. If you know the pixel values of a pixel and know how to convert fooRGB to XYZ there is absolutely no need to do the actual conversion. You can still claim that you know the XYZ as well as CIELAB coordinates. You just don't bother to do the conversion until you really need it. If you know that x is 5 and you know how to calculate the square of a given value you don't need to do the actual calculation. Yet you still "know" in the sense that the specific value is available to you as soon as you need it. > But here's a maxim for *RGB* image editing: > > For RGB editing operations, don't ever, ever, ever convert color-managed > fooRGB to unbounded sRGB. I assume that by "RGB editing operations" you're referring to the "math-centric" ones which bluntly apply a mathematical formula to the pixel data, not caring if the operation makes sense from a colorimetric/physics based viewpoint. (Examples would be "multiply" or even "levels" on the RGB channels). We now have operations who utterly need to know the colorimetric values of a pixel, because they are based on color theory. Shifting the color temperature of an image might be a good example. We have to be able to mix these operations, because Future Gimp (TM) will head towards non-destructive editing, where the user uses the UI to construct a graph of operations to combine all the image sources to get to the desired result. We don't intend to stick to the "have-an-image, do-an-operation, have-a-new-image, repeat" paradigm. So we need infrastructure that can mix both, the colorimetric and the math-centric approach. Your proposal of never-ever-converting will make real colorimetric operations a pain, since the color-temperature operation has to accept the fooRGB data, convert it to XYZ, do its operation and convert back to fooRGB, because fooRGB is ultimately what is needed for a potential next math-centric operation. With the infrastructure proposed by pippin the "math-centric" operations will ask for fooRGB data as input and provide fooRGB data as output. That means that chaining them together will neatly avoid colorspace conversions. If the user then decides to put a color-temperature change in the mix (lets assume it requests bablRGB as input and provides bablRGB as output, since the author decided against XYZ for some reason) Ge
Re: [Gimp-developer] [Gegl-developer] babl roadmap
On Oct 15, 2014 4:19 PM, "Elle Stone"
wrote:
>
> On 10/15/2014 08:30 AM, Øyvind Kolås wrote:
>
>> On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone wrote:
>
Hi, I fear you two are talking past eachother.
> I will ask again:
>
> For which specific RGB editing operations do you plan to convert the
image from fooRGB to unbounded sRGB before performing the operation?
>
> Either the answer is "None. For color-managed fooRGB images, all RGB
operations will be done on data encoded using fooRGB primaries."
The answer is (to best of my understanding): Typically none. When chosing
to work in myfavoriteRGB for one "scene" (can be a GIMP document), all
operations which specify that they work in any RGB color space, using
babl_format("scene:RGBA float") will operate on myfavoriteRGB data. So if
there is myfavoriteRGB image as input, and that also is the desired output,
there will be zero data conversions.
Supporting any RGB spaces should be the case for the vast majority of
operations dealing with RGB data, including multiply/invert and similar.
With respect to the roadmap, these operations are *currently wrongly
tagged* to only work in unbounded sRGB. This is only because we don't have
the new architecture implemented yet!
I say 'typically' because if some operation *does* specify
babl_format("RGBA float") to indicate that it just works with unbounded
sRGB, a conversion will happen. This should of course *only be used in some
cases*, when it actually just works with the specific format. I can't
immediably think of any usecase for this, but there probably are some.
I hope this addresses some of your concerns,
Regards Jon
___
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] [Gegl-developer] babl roadmap
On 10/15/2014 08:30 AM, Øyvind Kolås wrote: On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone When the user opens a color-managed fooRGB image, for which *specific* editing operations will the image be converted to unbounded sRGB? If the user is putting a text-layer, which has been rendered using cairo and is in 8bit sRGB premultiplied alpha. The compositing of this with preceding data in the layer stack the babl-format of the output buffer of the over/normal compositing operation, as well as the data fetched from both buffer inputs - would likely be RaGaBaA float - if the two linear inputs differ. I'm not sure why your text-layer stack example is relevant to my very direct and still unanswered question. But using GIMP 2.9, I put a text-layer over a color layer, first in a very large linear gamma (camera-based) color space, and then in a linear gamma color space with the sRGB primaries. In both color spaces, the text-rendering looked the same, even when magnified to 400%. Of course I used color management with a proper monitor profile, at 32-bit floating point precision. Is it possible that your color management settings are awry? Is it possible that the babl conversions between linear and perceptually uniform RGB are somehow messing up compositing text-layers over color layers? I used a modified version of babl/GEGL/GIMP in which the babl conversion between linear and perceptually uniform RGB are disabled. If you are saying that 8-bit images only work with the existing babl code if the images are also sRGB images, then perhaps a babl bug report is in order. Out there in the real world, some people do edit 8-bit AdobeRGB1998 images, even some people who are currently using 8-bit GIMP. If you are saying that 8-bit "premultiplied alpha" RGB data only works with sRGB images, again that would also seem to be a reason for filing a bug report against the babl code. Or at least it's a reason to warn people in the UI that 8-bit RGB data only works properly for sRGB images. At all points we know the CIE Lab or XYZ coordinates of all involved pixels You don't "know" the XYZ coordinates until you actually convert from fooRGB to XYZ. Likewise with CIELAB. So it's not clear what the above sentence really means. – and we aim to do as few conversions as possible As few conversions as possible sounds like an excellent maxim for writing image editing software. Whether you want to go through unbounded sRGB to get to XYZ, CIELAB, etc, for purposes of editing in a reference color space, is entirely irrelevant to RGB editing operations. But here's a maxim for *RGB* image editing: For RGB editing operations, don't ever, ever, ever convert color-managed fooRGB to unbounded sRGB. (never converting the actual data to either bablRGB or XYZ, Does "bablRGB" mean fooRGB data that's been converted to unbounded sRGB? even temporarily - unless requested.) Who does the requesting? The artist? Nope, the developers who write the code decide which color space the image data gets converted to. This brings us back to the main quesion: For which specific RGB editing operations do you plan to convert the image from fooRGB to unbounded sRGB before performing the operation(s)? With respect, Elle Stone ___ 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] [Gegl-developer] babl roadmap
On 10/15/2014 08:30 AM, Øyvind Kolås wrote: On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone wrote: 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? There is no plan to maintain lists in the end, this information would be self-contained within each individual operation, If each individual operation will carry information about whether the operation should use fooRGB primaries or sRGB primaries, then at some point someone must compile a list for the devs to consult. Unless you really mean to say: *DevA working on Op1 decides whether to use fooRGB primaries or sRGB primaries for Op1. *DevB working on Op2 decides whether to use fooRGB primaries or sRGB primaries for Op2. *DevC can decide DevA and DevB were both wrong and change the code. And so on. Consider the following: 1. RGB editing operations performed on fooRGB images using fooRGB primaries are *always* correct. 2. More than half of all operations on linear RGB are chromaticity-dependent. Many more than half of all operations on perceptually encoded RGB are chromaticity-dependent. *All* of these operations WILL produce *wrong* results after the image is converted to unbounded sRGB. So the developer choices are: 1. Either don't convert fooRGB images to unbounded sRGB for *any* RGB editing operations. Results will *always* be right. 2. Or else compile a list of all editing operations that "do work" and "don't work" in unbounded sRGB, and only convert the image to unbounded sRGB for the operations that "do work" in unbounded sRGB. And hope you get the list right, because you are messing with the user's RGB data for no good reason. I will ask again: For which specific RGB editing operations do you plan to convert the image from fooRGB to unbounded sRGB before performing the operation? Either the answer is "None. For color-managed fooRGB images, all RGB operations will be done on data encoded using fooRGB primaries." Or you are committing the devs to maintaining a formal or ad hoc list of operations on fooRGB data vs operations on unbounded sRGB data. And then you are committing the devs to writing per op code to implement entirely pointless conversions from fooRGB to unbounded sRGB and back again. With respect, Elle Stone ___ 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] [Gegl-developer] babl roadmap
On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone > 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: If the user is putting a text-layer, which has been rendered using cairo and is in 8bit sRGB premultiplied alpha. The compositing of this with preceding data in the layer stack the babl-format of the output buffer of the over/normal compositing operation, as well as the data fetched from both buffer inputs - would likely be RaGaBaA float - if the two linear inputs differ. At all points we know the CIE Lab or XYZ coordinates of all involved pixels – and we aim to do as few conversions as possible (never converting the actual data to either bablRGB or XYZ, even temporarily - unless requested.) > 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? There is no plan to maintain lists in the end, this information would be self-contained within each individual operation, like whether the operation needs CIE Lab, pre-multiplied alpha or not or even an 16bit linear grayscale. This automatic data representation conversion is an inherent abstraction and property both of GeglBuffer and the services provided for op authors to make implementing consistently behaving operations easy. /Ø ___ 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] [Gegl-developer] babl roadmap
On 10/14/2014 08:50 AM, Simon Budig wrote: Elle Stone (ellest...@ninedegreesbelow.com) 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 ___ 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
