Re: [Gegl-developer] [Gimp-developer] babl roadmap: How do you know which images are sRGB images?
Elle, "It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat." - Theodore Roosevelt Time for you to stop making vaguely patronising remarks and make an actionable suggestion, or leave this. Hugs and positivity, Ed -Original Message- From: Elle Stone Sent: Friday, October 17, 2014 4:43 PM Cc: gegl-developer-list ; Gimp-developer Subject: Re: [Gimp-developer] [Gegl-developer] babl roadmap: How do you know which images are sRGB images? On 10/14/2014 07:16 AM, Øyvind Kolås wrote: On Tue, Oct 14, 2014 at 11:20 AM, Elle Stone wrote: On 10/13/2014 06:36 PM, Elle Stone wrote: So again, upon opening an image, how do you plan to detect whether the image is an sRGB image or not? Will you compare MD5 checksums? Will you consult the profile descriptions? Will you examine the profile colorants and TRCs? Most likely examination of profile colorants/TRCs since that is what ICC or other color profile meta-data aware image loaders needs to provide down to babl anyways. You did pick the only plausible answer: check the colorants and TRCs. In many circumstances it is desirable to to treat almost sRGB as sRGB and consider deviance from the real standard a mistake in labeling; for instance if it is a low bitdepth image containing dithering - at other times assuming that the slight off profile has been applied as is earlier in the production pipeline might be desirable. For most users, for most purposes, you as developer can probably decide for the user that "slight off" means "close enough". The trouble is you don't know whether "slight off" is a mistake or intentional. The profile maker might have used something other than Bradford adaptation to make the profile. This is allowed by the ICC specs, and would result in slightly different colorants. The artist might be fully aware that the profile is not exactly like the GIMP built-in profile, and nonetheless intend to use the embedded sRGB profile instead of the GIMP built-in sRGB profile. Perhaps the existing gray axis needs to be preserved. And so on. You think it's OK to second-guess and decide for the artist what happens to the artist's RGB data. But it's really not OK. Elle Stone ___ gimp-developer-list mailing list List address:gimp-developer-l...@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] babl roadmap: How do you know which images are sRGB images?
On 10/17/2014 11:50 AM, Ed . wrote: Elle, Time for you to stop making vaguely patronising remarks Hmm, *who* has been making vaguely patronising remarks? and make an actionable suggestion, or leave this. I have made a very actionable suggestion: http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html https://bugzilla.gnome.org/show_bug.cgi?id=737778 Hugs and positivity, Ed, I don't believe you have a leg to stand on in this conversation. ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] babl roadmap
FYI, I'm not interested in continuing this discussion with Pippin. Twice it seemed that unbounded sRGB would be abandoned and that "sRGB-only" would be reserved for only those very few and easily identified RGB editing operations that really only could work in the sRGB color space. In my opinion, babl/GEGL/GIMP together make a great combination. The only thing I'm objecting to is Pippin's desire to shoehorn into the mix unbounded sRGB for RGB image editing. Right now I use three side-by-side babl/GEGL/GIMP installations for image editing, one each for the three different RGB working spaces that I use regularly (guess what, one of them is for sRGB). For each installation I changed the hard-coded Y values to match the Y values of the intended RGB working space (the GIMP hard-coded sRGB Y values are not correct, being D65 unadapted values). And I disabled the babl TRC flips. I don't ever use the XYZ-to-LAB conversion. Nor do I use the YCbCr/YIQ/color-temperature and so forth code. So all I needed to change to get accurate RGB editing operations was the hard-coded Y values. I have already posted a bug report and a write-up on how to fix GIMP color management, containing a (hopefully) complete list of all hard-coded sRGB and NTSC parameters: http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html https://bugzilla.gnome.org/show_bug.cgi?id=737778 I have tried to explain the problems shoehorning unbounded sRGB into the babl/GEGL/GIMP code base will cause. But unless some of the developers want to start a branch that won't use unbounded sRGB, I think it's time to stop the conversation. Unfortunately I don't know how to ferry UserRGB Y values to the places in the babl/GEGL/GIMP code that currently use hard-coded sRGB Y values. Otherwise I would submit a patch. But I did submit code for retrieving UserRGB Y and XYZ values. Kind regards, Elle Stone ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] babl roadmap
On 10/17/2014 08:32 AM, Øyvind Kolås wrote: GIMP is not the only project using GEGL; nor is it the only user interface on top of GEGL. GEGL pipelines need to be able to deal with arbitrary counts of RGB spaces; which also GIMP need for having multiple project use open and doing cross project copy-paste, clone etc. One of the other GEGL UIs is this http://libregraphicsworld.org/blog/entry/artificial-intelligence-designs-websites-uses-open-technology-stack That project isn't using unbounded sRGB. I will guess that as a web application, all image editing is limited to sRGB images. Web browser color management is iffy, at best. So sRGB is still the safest choice for the web. ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] babl roadmap
Unfortunately for hard-coded "sRGB as PCS", the ICC profile specifications are a moving target. Right now the ICC profile illuminant is always D50. But in the next planned release of new specifications, things will change: //begin quote from http://color.org/DevCon/devcon14.xalter While this fixed PCS is capable of delivering unambiguous color transforms, it cannot support the increasing demand for spectrally-based reproduction. iccMAX is a radically different approach which builds on ICC v4 but enables a far more flexible means of connecting devices, data, materials, observers and illuminants. //end quote I would ask every babl/GEGL/GIMP developer who cares about GIMP as a high end ICC profile color-managed image editor to read the rest of the page that I just linked to, and maybe think long and hard about whether you really want to limit yourself to "babl color management" based on hard-coded D50-adapted "sRGB as PCS". D65 unadapted sRGB is based on CRT technology that is no longer in widespread use. Rec.2020 is the up and coming new display device standard. D50-adapted ICC profiles are based on profile specifications that revolve around increasing outdated print-based technologies. Print-making technologies have changed, and today the output device is just as (or more) likely to be a display screen. The ICC is moving forward (and let's hope they also fix a few issues that V4 introduced). Tying GIMP to "sRGB as PCS" is a dead-end move. Kind regards, Elle Stone -- http://ninedegreesbelow.com Color management and free/libre photography ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] babl roadmap
In the current babl/GEGL/GIMP code base, I counted five files that contain functions that require a conversion from RGB to XYZ: 1. gimp/plug-ins/common/decompose.c 2. gimp/plug-ins/common/compose.c 3. gimp/app/core/gimpimage-convert-type.c 4. gegl/operations/common/image-compare.c 5. gegl/operations/common/noise-cie-lch.c These five files use the babl file: babl/extensions/CIE.c The babl/extensions/CIE.c code calculates the "sRGB to XYZ" matrix "M", starting from the D65 unadapted sRGB color space red, green, blue, and white xy values. Calculating "M" from xy values is a fairly complicated process. Study the equations on http://brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html and make sure to read note 2, which says "Be careful that reference whites are used consistently. For example, sRGB is defined relative to a D65 reference white and ICC profiles are defined relative to a D50 reference white. Mismatched reference whites must be accounted for elsewhere, typically by using a chromatic adaptation algorithm." In an ICC profile D50-adapted color-managed workflow, you don't use the unadapted D65 sRGB "M" (that the babl code calculates) to get from sRGB to XYZ. In an ICC profile color-managed workflow, you don't need to calculate the D50-adapted "M" for a matrix RGB working space, because you can read "M" directly from the ICC profile colorants. There are two ways to fix the "conversion to XYZ" code in babl/extensions/CIE.c: 1. babl/extensions/CIE.c can be rewritten to use D50-adapted "M" retrieved directly from the UserRGB ICC profile colorants. Then convert to XYZ. 2. Or else you can use "sRGB as PCS", which allows you to rewrite the code in babl/extensions/CIE.c to use hard-coded D50-adapted sRGB "M". In this case: i. Upon opening an image, first retrieve "M" from UserRGB (call this matrix "A"). ii. Then retrieve "M" from sRGB and calculate the inverse (call this matrix "C"). iii. Then calculate "C*A" and store this information in memory as "D". iv. Then convert from UserRGB to unbounded sRGB using the matrix "D". v. Then convert from unbounded sRGB to XYZ using the hard-coded D50-adapted sRGB M. In an ICC profile color-managed workflow, sRGB is just another ICC working space profile. It doesn't need special treatment. The right way to fix the babl conversion to XYZ is to rewrite babl/extensions/CIE.c to use "M" taken from the UserRGB ICC profile colorants. And forget about "sRGB as PCS". There may be a problem somewhere in the GIMP code for which "sRGB as PCS" might be a solution. Converting to XYZ is not one of those problems. Kind regards, Elle Stone -- http://ninedegreesbelow.com Color management and free/libre photography ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] babl roadmap
On Fri, Oct 17, 2014 at 12:01 PM, Elle Stone wrote: > On 10/16/2014 03:37 PM, Øyvind Kolås wrote: >> >> On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone >> wrote: >>> >>> 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? >> >> >> the first thing we should do is to >> annotate all the operations which are broken when done with sRGB >> primaries > > > In other words, you will make a list of all operations that "don't work" in > unbounded sRGB, and then you will convert from unbounded sRGB to UserRGB for > those operations, and then back to unbounded sRGB. Good luck with that. > >> 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. > > > As a maxim for guiding GIMP development, "consistent results for the same > property values / slider positions" reflects a profound failure to > understand the nature of RGB image editing and can only lead to bad code. No I am explaining how we will start out making these changes for engineering reasons. How to follow a process that doesn't destabilize and destroy what we already have. While your back-seat driving, asking about detailed choices of side-roads 4 weeks from now on our road-trip is not very productive when we're not even sure we'll be in the country of those roads you want us to take – or if we will have swapped the hummer for a jeep. ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] babl roadmap
On 10/14/2014 08:50 AM, Simon Budig wrote: for conversions between RGB working spaces there is no fundamental distinction between XYZ and unbounded linear gamma sRGB. There is one fundamental difference between XYZ as the real PCS and "sRGB as PCS" (those are scare quotes; the terminology "sRGB as PCS" is misleading at best): Worked out step by step: It takes one matrix multiplication to get from UserRGB to XYZ. The required matrix "A" is contained in the UsrRGB ICC profile colorants. It takes a second matrix multiplication to get from XYZ to sRGB. The required matrix "C" is the inverse of the matrix contained in the sRGB ICC profile colorants. A and C are both defined in terms of XYZ. Once you have matrix A for getting from UserRGB to XYZ and matrix C for getting from XYZ to sRGB, you can concantenate the two multiplications into one matrix multiplication. This is because matrix multiplication is associative: C*(A*B) = (C*A)*B, where B is the UserRGB RGB values that will be converted to sRGB (linearized RGB data is assumed). One matrix multiplication or two, you still get to the same place. But the required "one matrix to multiply" first has to be *calculated* using *two* matrices, both of which are defined in terms of the real PCS, which is XYZ. Then you have to store the result of C*A in memory for future use. Pippin wants to go through "sRGB as PCS" to get to XYZ. In a sane color-managed editing application, it takes one matrix multiplication to get from UserRGB to XYZ, using matrix A. In Pippin's "sRGB as PCS", first you convert from UserRGB to sRGB using the matrix that's the product of C*A, that you've previously stored somewhere in memory. Then you convert from sRGB to XYZ using the inverse of C. Two conversions. Which of course can in turn be concantenated into one multiplication and also stored in memory for future use. Kind regards, Elle Stone -- http://ninedegreesbelow.com Color management and free/libre photography ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] babl roadmap
On 10/16/2014 03:37 PM, Øyvind Kolås wrote: On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone wrote: 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? the first thing we should do is to annotate all the operations which are broken when done with sRGB primaries In other words, you will make a list of all operations that "don't work" in unbounded sRGB, and then you will convert from unbounded sRGB to UserRGB for those operations, and then back to unbounded sRGB. Good luck with that. 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. As a maxim for guiding GIMP development, "consistent results for the same property values / slider positions" reflects a profound failure to understand the nature of RGB image editing and can only lead to bad code. With respect, Elle Stone ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] babl roadmap
On Fri, Oct 17, 2014 at 12:49 AM, Jon Nordby wrote: > you are answering in detail 'how we will get "there"' but Elle (as I see it) > is asking more 'do you agree that we want to go "there"'. This leaves me > unsure if you are implicitly agreeing, if you disagree and have a different > "there" in mind, or if you think it is too early to decide this. > > "There" being the goal that *eventually* in GEGL 'For RGB editing > operations, use UserRGB primaries *unless* there's a really, really good > reason why only sRGB primaries will work.' All of the above. I'm stating in detail how we will get as far as I can see into the future; which will bring us closer to "there". As well as reasons it probably will not a be binary choice when we have more knowledge of the capabilities and constraints. The level of detail of the roadmap is in places already too high as it both tries to document an intermediate state as well as hint at where we possibly want to go from there - and bits of what it documents will probably already be invalid by the time much of it is in place. /Ø ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] babl roadmap
On 16 October 2014 21:37, Øyvind Kolås wrote: > On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone > 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. Hi pippin, you are answering in detail 'how we will get "there"' but Elle (as I see it) is asking more 'do you agree that we want to go "there"'. This leaves me unsure if you are implicitly agreeing, if you disagree and have a different "there" in mind, or if you think it is too early to decide this. "There" being the goal that *eventually* in GEGL 'For RGB editing operations, use UserRGB primaries *unless* there's a really, really good reason why only sRGB primaries will work.' -- Jon Nordby - www.jonnor.com ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] babl roadmap
On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone 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. /Ø ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] babl roadmap
On 10/15/2014 01:46 PM, Simon Budig wrote: 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? 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. You make a very fair point. A better way to ask my question would have been "By what criteria will the devs decide whether an RGB operation should use sRGB primaries instead of UserRGB primaries?" The babl roadmap says gamma slider and multiply compositing will be done using UserRGB. The roadmap's implied criteria for which RGB operations use sRGB primaries seems to be "If it works in unbounded sRGB, use sRGB primaries; otherwise use UserRGB primaries". 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? "For RGB editing operations, use UserRGB primaries except in the rare cases for which only sRGB primaries will work." Kind regards, Elle Stone ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-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 ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-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-list@gnome.org
> List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
>
>
___
gegl-developer-list mailing list
List address:gegl-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-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
___
gegl-developer-list mailing list
List address:gegl-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-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 ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-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 ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-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. /Ø ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-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 ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] babl roadmap
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 ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] babl roadmap
On 10/14/2014 07:52 AM, Øyvind Kolås wrote: On Tue, Oct 14, 2014 at 1:34 PM, Elle Stone wrote: To convert images to and from unbounded linear gamma sRGB, you MUST pass through XYZ. XYZ is the PCS. I remind you that linear RGB spaces are a single matrix multiplication away from other linear RGB spaces and XYZ. Matrix conversions between RGB working spaces can be concantenated. That concantenation goes through XYZ. It almost sounds like you want to obscure this fundamental distinction between XYZ and unbounded linear gamma sRGB. Let's cut to the chase: Are you planning on converting non-sRGB images to unbounded linear gamma sRGB? Yes or no? Foo or bar? Do you have any idea what "implementation detail" means? I do know what "implementation detail" means. You didn't the question, so I'll try again: Are you planning on converting non-sRGB images to unbounded linear gamma sRGB? Yes or no? 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? With respect, Elle Stone ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] babl roadmap
On Tue, Oct 14, 2014 at 1:34 PM, Elle Stone wrote: > The above sentence confuses concepts: The babl architecture might require > that images to be converted to and from unbounded linear gamma sRGB. That > doesn't mean babl is a CMS. And it doesn't mean unbounded linear gamma sRGB > has been turned into a PCS. Babls role in the GEGL and thus GIMP architecture is to be the internal CMS; this remains unchanged since babl was split out of a non-linear video editor/compositing system. > > To convert images to and from unbounded linear gamma sRGB, you MUST pass > through XYZ. XYZ is the PCS. I remind you that linear RGB spaces are a single matrix multiplication away from other linear RGB spaces and XYZ. > Let's cut to the chase: > > Are you planning on converting non-sRGB images to unbounded linear gamma > sRGB? Yes or no? Foo or bar? Do you have any idea what "implementation detail" means? /pippin ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] babl roadmap
On 10/14/2014 06:54 AM, Øyvind Kolås wrote: >So now all chromaticity-dependent editing operations will require a brand >new "special "specifying"", unless the image is already an sRGB image. > >If you didn't intend to convert all images to unbounded sRGB for editing, >there wouldn't be any reason to "special "specify"" roughly half of all the >editing operations that you offer through the GIMP UI. Just like in an ICC based workflow images are converted to unbounded XYZ for editing? (they are not) My apologies, I don't have a clue what you mean by what you just said. But no, XYZ isn't a good color space for image editing, if that is what you are asking. The PCS used by a CMS is an implementation detail; where choices might have been XYZ, linear sRGB or some other linear RGB; of the preceding linear sRGB has nicer properties than any of the others. The above sentence confuses concepts: The babl architecture might require that images to be converted to and from unbounded linear gamma sRGB. That doesn't mean babl is a CMS. And it doesn't mean unbounded linear gamma sRGB has been turned into a PCS. To convert images to and from unbounded linear gamma sRGB, you MUST pass through XYZ. XYZ is the PCS. Let's cut to the chase: Are you planning on converting non-sRGB images to unbounded linear gamma sRGB? Yes or no? 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? With respect, Elle Stone ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] babl roadmap
On Tue, Oct 14, 2014 at 12:34 AM, Elle Stone wrote: > You designed an architecture around converting images to unbounded sRGB for > editing. > > After 6 months of trying to show you that your architecture has serious > built-in problems, you finally believe me, or at least you believe Mansencal > and Sayre. But you want to keep the architecture anyway. We've acknowledged that chromaticities matter for more than the last half year - and proposed to extend the architecture in ways that doesn't break other parts of the architecture. We change what we have, and avoid fixing what isn'r broken - while trying to address short-coming like you've pointed out. > So now all chromaticity-dependent editing operations will require a brand > new "special "specifying"", unless the image is already an sRGB image. > > If you didn't intend to convert all images to unbounded sRGB for editing, > there wouldn't be any reason to "special "specify"" roughly half of all the > editing operations that you offer through the GIMP UI. Just like in an ICC based workflow images are converted to unbounded XYZ for editing? (they are not) The PCS used by a CMS is an implementation detail; where choices might have been XYZ, linear sRGB or some other linear RGB; of the preceding linear sRGB has nicer properties than any of the others. /Ø ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
