Hi Elle.

Sorry, I can't comment on most of these issues. However there is one important caveat:

Elle Stone (l.elle.stone@gmail.com) wrote:

*16-bit tiffs open without the erroneous "gamma 2.2 correction" being applied

16 bit loading code in the tiff plugin is highly experimental and I am not at all sure that it does the correct thing.

I just committed a bugfix for Bug #678815 https://bugzilla.gnome.org/show_bug.cgi?id=678815

which fixes loading issues with some tiffs. I failed to properly specify the format that the tiff plugin uses to transmit the data to the core.

Basically all of the plugins (including your lcms port) use the old pixel-region API for accessing the image data. This also means that they don't specify a proper working format, this even could be the reason for all kind of potentially useless conversions.

I suspect several other weird gamma 2.2/0.45 errors also might be related to the babl/babl/util.h functions.

But I have the strong impression that no-op'ing a core function is the wrong thing to do. It is much more likely, that the plugins mis-specify their working format and subsequently bogus stuff is happening.

Maybe this helps?

Bye, Simon

On 29 August 2012 19:03, Elle Stone wrote:

Why does /babl/babl/util.h provide functions that transforms back and forth between linear gamma TRC and the regular sRGB TRC? I'm sure there is a reason, but the reason is not apparent to me.

Babl is a pixel format conversion library. It can convert between RGB pixel representations with linear gamma and gamma-corrected, separate alpha channel and premultiplied alpha, or to/from other pixel formats like HSV, HSL, LAB.

Why does the /babl/babl/util.h code get executed from fast-float.c, float.c, model-rgb.c, model-gray.c, and several other files, resulting in endlessly performed conversions between linear and regular sRGB TRC in the background of all image processing?

That conversion from linear gamma to the sRGB tone response curve and back gets executed literally hundreds of thousands of time, every time you do anything at all using Gimp.

Rendering to to screen / the windowing system is done using sRGB. So anything that causes canvas updates when the image itself is not in sRGB will trigger such conversions.
Also, any legacy code paths that are still in place before the GEGLification might cause conversions to sRGB. I don't know exactly which parts those are in the current codebase, but anything that uses the deprecated pixel manipulation functions are likely candidates. I note that the lcms plugin still uses these interfaces, and I suspect that is what is causing the implicit (and unwanted) conversions you are seeing.

On 30 August 2012 01:01, Elle Stone wrote:

Regarding sRGB and rendering to the screen: On 8/29/12, Jon Nordby wrote:

On 29 August 2012 19:03, Elle Stone wrote:

Why does the /babl/babl/util.h code get executed from fast-float.c, float.c, model-rgb.c, model-gray.c, and several other files, resulting in endlessly performed conversions between linear and regular sRGB TRC in the background of all image processing?

Rendering to to screen / the windowing system is done using sRGB. So anything that causes canvas updates when the image itself is not in sRGB will trigger such conversions.

Could you explain more about what you mean by "rendering to the screen is done using sRGB"? What about the actual monitor profile?

Cairo, the library used for rendering to the screen in GTK and GIMP expects its input as sRGB*. See app/display/gimpdisplayshell.c for example of how we use this library. The Babl format "cairo-ARGB32" is short for "R'aG'aB'aA u8": 8 bit unsigned integer gamma-corrected, pre-multiplied alpha. The LCMS plugin is used before this step to do the conversion with the actual monitor profile.

* It is unclear to me how strict this expectation is as this is not documented anywhere in Cairo. Perhaps someone here can shed some more light?

Back in the day, a decent CRT monitor could easily be calibrated to match the sRGB color space, because sRGB was based on the display characteristics (tone curve, primaries, "dial-a-white-point" and 0 black point) of the CRT monitor. (See "All the Colors, Some of the Colors, the Colors of Daylight":
http://ninedegreesbelow.com/photography/all-the-colors.html).

Today's LCD monitors are not well-characterized by sRGB. It is not just a matter of the LCD monitor native white point not being D65. The phosphors are different, which means the primaries are different, which means the color gamut is different. And unlike a CRT, with an LCD you can't get (0,0,0) displayed to the screen (the sRGB black point assume "zero light" can be sent to the screen). Which means you cannot really calibrate your monitor to use the sRGB TRC. (See "sRGB — Not So Good for LCD Monitors":
http://ninedegreesbelow.com/photography/srgb-bad-monitor-profile.html and "Image Display Technology": http://www.marcelpatek.com/LCD.html.)

A wide gamut monitor profiled in its native state would be an even worse fit to sRGB, though compared to a regular LCD, a wide gamut LCD monitor can achieve a much closer calibration to sRGB, IF one chooses to give up the extra color gamut. But why would you want to give up all that extra color gamut goodness?

An RGB30 (10 bits per channel) image format was added in Cairo 1.12 earlier this year. I don't know if any if the display backends used on Linux, Mac OSX or Windows handles this format yet. It could be the output it still clamped or converted to 8 bit per channel even on wide gamut displays. I highly suspect that would be the case on X11.

On 30 August 2012 12:11, Jon Nordby wrote:

On 30 August 2012 01:01, Elle Stone wrote:

Regarding sRGB and rendering to the screen: On 8/29/12, Jon Nordby wrote:

On 29 August 2012 19:03, Elle Stone wrote:

Why does the /babl/babl/util.h code get executed from fast-float.c, float.c, model-rgb.c, model-gray.c, and several other files, resulting in endlessly performed conversions between linear and regular sRGB TRC in the background of all image processing?

Rendering to to screen / the windowing system is done using sRGB. So anything that causes canvas updates when the image itself is not in sRGB will trigger such conversions.

Could you explain more about what you mean by "rendering to the screen is done using sRGB"? What about the actual monitor profile?

Cairo, the library used for rendering to the screen in GTK and GIMP expects its input as sRGB*. See app/display/gimpdisplayshell.c for example of how we use this library. The Babl format "cairo-ARGB32" is short for "R'aG'aB'aA u8": 8 bit unsigned integer gamma-corrected, pre-multiplied alpha. The LCMS plugin is used before this step to do the conversion with the actual monitor profile.

Corrections : the LCMS display filter module is used, not the LCMS plugin. File: modules/display-filter-lcms.c The conversion is done _after_ the image has been rendered into the Cairo image buffer. See the call to
gimp_color_display_stack_convert_surface in gimpdisplayshell-renderer.c

On Thu, 2012-08-30 at 07:55 -0400, Elle Stone wrote:

On 8/30/12, Jon Nordby wrote:

On 30 August 2012 01:01, Elle Stone wrote:

Regarding sRGB and rendering to the screen: Could you explain more about what you mean by "rendering to the screen is done using sRGB"? What about the actual monitor profile?

Cairo, the library used for rendering to the screen in GTK and GIMP expects its input as sRGB*. See app/display/gimpdisplayshell.c for example of how we use this library. The Babl format "cairo-ARGB32" is short for "R'aG'aB'aA u8": 8 bit unsigned integer gamma-corrected, pre-multiplied alpha. The LCMS plugin is used before this step to do the conversion with the actual monitor profile.

So if I understand what you are saying (I don't think I do): First the lcms plugin converts the image to the actual monitor display profile. Then "something" converts the image to sRGB and sends the image to Cairo? And then Cairo sends the image to the screen?

I don't think that is what really happens. If it were happening, all images displayed by Gimp would have a magenta color cast as displayed on my monitor. And they don't. Perhaps Cairo just sends RGB numbers to the screen (and doesn't care what these numbers "mean"), and Gimp is sending the monitor profile RGB numbers to Cairo.

Don't work under the assumption that anything in git master works as it should. It's safe to assume that *nothing* works as it should, and needs to be fixed. So if something doesn't seem to work, the bug could be in many places.

--mitch

On Thu, Aug 30, 2012 at 3:55 PM, Elle Stone wrote:

So if I understand what you are saying (I don't think I do): First the lcms plugin converts the image to the actual monitor display profile. Then "something" converts the image to sRGB and sends the image to Cairo? And then Cairo sends the image to the screen?

I don't think that is what really happens. If it were happening, all images displayed by Gimp would have a magenta color cast as displayed on my monitor. And they don't. Perhaps Cairo just sends RGB numbers to the screen (and doesn't care what these numbers "mean"), and Gimp is sending the monitor profile RGB numbers to Cairo.

FYI, color management in Cairo is a work in progress. Adrian needs input on desired API, though. Without it he cannot proceed further.

http://inkscape.13.n6.nabble.com/Creating-color-managed-PDFs-td4964914.html

Alexandre Prokoudine http://libregraphicsworld.org

On Thu, Aug 30, 2012 at 4:41 PM, Alexandre Prokoudine wrote:

FYI, color management in Cairo is a work in progress. Adrian needs input on desired API, though. Without it he cannot proceed further.

http://inkscape.13.n6.nabble.com/Creating-color-managed-PDFs-td4964914.html

Also, http://cgit.freedesktop.org/~ajohnson/cairo/log/?h=color-space

Alexandre Prokoudine http://libregraphicsworld.org

Am 30.08.2012 13:55, schrieb Elle Stone:

So if I understand what you are saying (I don't think I do): First the lcms plugin converts the image to the actual monitor display profile. Then "something" converts the image to sRGB and sends the image to Cairo? And then Cairo sends the image to the screen?

If I'm not entirely mistaken then there should be only one real conversions. In this lcms would convert the linear color to a pseudo sRGB, which is actually the monitor display profile. This is because Cairo only supports sRGB and does no conversion to the monitor profile on it's own. So the colors have to be converted before passing them them to Cairo (regardless if sRGB or RGB30).

Bit depth and ICC profile color gamut are two different things. Bit depth determines how many steps to get from min to max. For example, 8-bits gives you 255 steps to get from solid green (0,255,0) to solid yellow (255,255,0). 10 bits gives you 1023 steps to cross the same distance. But the "meaning" of solid green and solid yellow is determined by where the monitor profile (or any other ICC profile) locates solid green and solid yellow in an reference space (profile connection space) such as XYZ or Lab space.

Kind regards, Elle

Right. I do not really understand why the conversions should be such painfull. Ideally all image data (except alpha) should be handled as linear internally. This has effectively nothing to do with color management (only depth conversion), except that we want to give every channel/layer a own profile to avoid rounding errors on low bit depth. Rounding errors would occur if we have a 8bit sRGB image and would convert it to 8bit linear RGB. So we have a dilemma:

A) Storing everything as 32bit float linear RGB would dramatically decrease programming overhead and computation time (no color conversion, except for final output), but it would consume a great amount of RAM for just 8 or 16 bit images.

B) Leaving the the values as they are and doing conversions every time a pixel is accessed saves a lot of RAM. The downside is that every pixel has to be converted from "channel" profile and depth to another profile and depth if doing some stuff. This could be drastically speed up if there are specialized methods that can do the operation the short way, but i doubt that it would be beneficial to implement all permutations.

Personally i would favor scheme A) since performance is one of my biggest concerns for GIMP right now. RAM is important, but it doesn't really matter as much. This steady conversions from one color space to another are really a performance killer.

Option C) would be a cache for Option B) that keeps the image data as it is (uncoverted, original bit depth), but stores the pixel information as linear RGB 32 bit. But it would not store the whole layer, it would just store what is "On Screen", already resized, transformed, etc, but not flattened. That way only one layer must be converted (cache->layer) while drawing.

Kind regards,
Tobias Oelgarte

On 30 August 2012 13:55, Elle Stone wrote:

On 8/30/12, Jon Nordby wrote:

On 30 August 2012 01:01, Elle Stone wrote:

Regarding sRGB and rendering to the screen: Could you explain more about what you mean by "rendering to the screen is done using sRGB"? What about the actual monitor profile?

Cairo, the library used for rendering to the screen in GTK and GIMP expects its input as sRGB*. See app/display/gimpdisplayshell.c for example of how we use this library. The Babl format "cairo-ARGB32" is short for "R'aG'aB'aA u8": 8 bit unsigned integer gamma-corrected, pre-multiplied alpha. The LCMS plugin is used before this step to do the conversion with the actual monitor profile.

So if I understand what you are saying (I don't think I do): First the lcms plugin converts the image to the actual monitor display profile. Then "something" converts the image to sRGB and sends the image to Cairo? And then Cairo sends the image to the screen?

You understood me correctly, but what I said it turned out to be wrong. Quoting myself from the follow up email:

"Corrections : the LCMS display filter module is used, not the LCMS plugin. File: modules/display-filter-lcms.c The conversion is done _after_ the image has been rendered into the Cairo image buffer. See the call to
gimp_color_display_stack_convert_surface in gimpdisplayshell-renderer.c"

So the pipeline is at the moment:

GeglBuffer (format depending on image precision setting) -> | gegl_buffer_get | -> sRGB (without a profile or with the profile of the document?) -> | display filter stack | -> sRGB in monitor profile -> | Cairo |

This is actually one more conversion and one step earlier than we need to. Ideally the pipeline should look like this:

GeglBuffer -> | display filter stack | -> sRGB in monitor profile -> | Cairo |

That way we only convert to the monitor profile as a last step. This would require GEGLifying the display filter stack and all the modules it uses.

I don't think that is what really happens. If it were happening, all images displayed by Gimp would have a magenta color cast as displayed on my monitor. And they don't. Perhaps Cairo just sends RGB numbers to the screen (and doesn't care what these numbers "mean"), and Gimp is sending the monitor profile RGB numbers to Cairo.

Yes, you are probably right that Cairo itself does not care about the meaning of the RGB values, and that this is up to the display system and screen.

I'll only reply to the question in the topic, repeating quite a bit of the information I put in a write up two weeks ago: http://gimp.1065349.n5.nabble.com/GIMP-GEGL-storage-precision-and-color-management-td34899.html

When operating in 8bit precision is that a GEGL powered GIMP assumes that 8bit precision data is stored with sRGB gamma (this will probably be changed to apply to 16bit integer as well), data with higher bit-depths are stored with a linear gamma ramp in the layer buffers.

The working space of the layer modes currently used by GIMP are implemented with sRGB gamma based compositing, thus for higher bit-depth data - we must convert from linear to the sRGB working space - perhaps go back to linear for some other operation, and in most cases we convert back to 8bit sRGB for display (with proper color management we'd go from higher bit-depth to the displays ICC profile or similar). All these legacy 8bit layer modes are scheduled for replacement with operations working in linear light (linear gamma) - at that stage a lot of conversions back and forth (in floating point) will be avoided.

Importing 8bit or 16bit images that do not contain sRGB data - should result in precision promotion to probably 32bit floating point, where the data can be well represented ... pending a _potential_ conversion back to the source ICC profile. Note that babl's built in floating point representations have unbounded gamuts thus can represent all of sRGB / ProRGB / AdobeRGB and data with other 8bit profiles. Using the sRGB for 8bit and 16bit integer precisions means that (web destined) JPG and 8bit/16bit PNGs without associated profiles should be possible to directly manipulate.

/

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Thu, Aug 30, 2012 at 8:08 PM, Elle Stone wrote:

On 8/30/12, yvind Kols wrote:

I'll only reply to the question in the topic, repeating quite a bit of the information I put in a write up two weeks ago: http://gimp.1065349.n5.nabble.com/GIMP-GEGL-storage-precision-and-color-management-td34899.html

When operating in 8bit precision is that a GEGL powered GIMP assumes that 8bit precision data is stored with sRGB gamma (this will probably be changed to apply to 16bit integer as well), data with higher bit-depths are stored with a linear gamma ramp in the layer buffers.

But this is a ***very wrong*** assumption. Many people work with 8-bit images that are NOT sRGB images and DON'T use the sRGB TRC (AppleRGB, ColorMatch, LStar, etc).

sRGB, AppleRGB and other 8bpc representations are a work-around for the limited values expressable in 8bit - you are better off doing the actual processing in linear light RGB and not permitting these arbitrary working spaces; this reduces this other spaces to be a space efficient way of packing the color data into 8bit.

Note that babl's built in floating point representations have unbounded gamuts thus can represent all of sRGB / ProRGB / AdobeRGB and data with other 8bit profiles. Using the sRGB for 8bit and 16bit integer precisions means that (web destined) JPG and 8bit/16bit PNGs without associated profiles should be possible to directly manipulate.

In point of fact the extended scRGB does NOT cover all of the ProPhotoRGB color space or the CIE 1931 color space. scRGB leaves out a good chunk of the all-important greens.

Quoting from Wikipedia, which has a very nice picture that everyone ought to go take a look at: http://en.wikipedia.org/wiki/ScRGB

"Negative numbers enables scRGB to encompass most of the CIE 1931 color space while maintaining simplicity and backward compatibility with sRGB ***without the complexity of color management***. The cost of maintaining compatibility with sRGB is that approximately 80% of the scRGB color space consists of imaginary colors."

The point of scRGB is MicroSoft's and Hewlett-Packard's attempt to yet again not deal with color management. But color management is part and parcel of all high end image editors, and well-integrated with Linux. So why on earth would any Linux image editor want to follow in the MS/HP footsteps and use scRGB, with the attendant loss of ability to represent all of the real world colors and the attendant requirement of using very high bit depths to maintain image integrity?

The "RGBA float" space of babl does not leave out greens, blues, purples or imaginary colors of any magnitude. The entirety of the tristrimulus gamuts expressable in any RGB triplet space can be expressed. (granted some parts of this 32bit floating point representation is not the most _useful_ real world colors, but no colors are being left out).

If you stick with normal, well-accepted working spaces like ProPhotoRGB and BetaRGB, you can edit using 16-bits without banding. If you force image data into the scRGB color space, to maintain the same degree of accuracy/lack of banding you will ***need*** to go to 32-bit/64-bit floating point, because of the way scRGB works. That is the price you pay for having 80% of your working space occupied by imaginary colors. That will place a huge and unnecessary overhead on image editing with Gimp.

You were yourself arguing for linear light processing earlier ;) To me this is about doing things more correctly and not rely on the legacy of 8bpc hacks. Moving the 8bpc hacks over to be properly color manages (having completely user defined arbitrary working spaces for operations like blur and compositing is not really a color managed workflow). All processing in a GEGLified GIMP is already happening in 32bit float, the additional overhead to pay by using single (or half (16bit)) precision float for storing image content is not a large price to pay for accurate color management.

Right now the default babl/base/util.h DOES NOT WORK with any 16-bit image that doesn't have the sRGB TRC. Please see this page for an example using Gegl blurring:
http://ninedegreesbelow.com/temp/gimp29-gegl-blur-prophoto.html

My color conversion code is NOT involved in blurring, and to make double sure, I replaced my lcms2 plug-in with the default Gimp lcms plug-in. The Gegl blurring ONLY works with images that have the sRGB TRC.

Your assessments on what works when opening your image files has little bearing on correctness of what is going on. Your changes to babl is equivlent to declaring that black and white is the same thing and complaining about being run over by cars in a zebra crossing. ;)

With increasing dismay, but still with warmest regards, Elle Stone

I do hope you stick around, we need people able to understand color and the implications of controlling it properly. But it seems like you think we're 98% done with dealing with color in the brave new world of geglified GIMP while the truth is that we're probably ~20% there. Very few things are expected to work correctly right now and the rest can be figured out as we're gaining more solid ground.

/

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Fri, Aug 31, 2012 at 12:30 AM, yvind Kols wrote:

In point of fact the extended scRGB does NOT cover all of the ProPhotoRGB color space or the CIE 1931 color space. scRGB leaves out a good chunk of the all-important greens.

Quoting from Wikipedia, which has a very nice picture that everyone ought to go take a look at: http://en.wikipedia.org/wiki/ScRGB

"Negative numbers enables scRGB to encompass most of the CIE 1931 color space while maintaining simplicity and backward compatibility with sRGB ***without the complexity of color management***. The cost of maintaining compatibility with sRGB is that approximately 80% of the scRGB color space consists of imaginary colors."

The point of scRGB is MicroSoft's and Hewlett-Packard's attempt to yet again not deal with color management. But color management is part and parcel of all high end image editors, and well-integrated with Linux. So why on earth would any Linux image editor want to follow in the MS/HP footsteps and use scRGB, with the attendant loss of ability to represent all of the real world colors and the attendant requirement of using very high bit depths to maintain image integrity?

The "RGBA float" space of babl does not leave out greens, blues, purples or imaginary colors of any magnitude. The entirety of the tristrimulus gamuts expressable in any RGB triplet space can be expressed. (granted some parts of this 32bit floating point representation is not the most _useful_ real world colors, but no colors are being left out).

You should also note that babl's "RGBA float" format is not inspired by or defined by scRGB, but could more well be described as a linear light / physical color space, with the same RGB primaries as sRGB, a linear gamma curve, white at 1.0, 1.0, 1.0 - black at 0,0,0 extendable towards the limits of floating point representation negatively and positively.

It has been pointed out to me that this in some way resembles some aspect of scRGB - however I arrived at the behavior of the space before I ever looked at anything that had to do with it. To do color management properly - the important thing is to tag all your buffers with the relevant color profile, a proliferation of "source data profiles", "standard press profiles", "optimized 8bit working spaces" and more does not help the user keep their colors under control, instead it makes it easier to mis-configure your workflow/system. Building a system around linear light instead of gamma encoded processing; with strict coordination of the color spaces involved should lead to more predictable control over results.

With the strict color management architecture of GEGL - you would lose the memory gains from storing layer data in lower precision with custom profiles in terms of additional conversions that would then be necessary for when temporarily linearising data and increasing precision for 32bit processing (and back again to destructively store the new results). In the future when the system is in place; there is the option to add direct 8bpc and 16bpc fast paths for sRGB processing (as well as maybe add ugly hacks permitting the user to pretend that the 8bit or 16bit data is not in sRGB but some other space; including problems resulting from gamma problems then present when blurring, scaling, compositing and more...) neither of those are something I'd consider of importance until basics are covered.

/ --

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Fri, Aug 31, 2012 at 7:37 PM, Elle Stone wrote:

I keep coming back to this question. If your goal is to convert all images to your linear light working space for image processing, why not do the conversion one time and be done with it?

Isn't it what yvind defined as a noble goal in his mail few weeks ago? :)

Didn't he also say that the relevant part of code is more like 20% done and hence should not be treated as what the team had in mind for final design? :)

Alexandre Prokoudine http://libregraphicsworld.org

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Am 31.08.2012 18:27, schrieb Elle Stone:

The ultimate goal of working in a linear light color space is both clear and noble.

I support this. Working in linear light color space has many advantages. One of them is the potential speed. The other would be tools that only need to work inside one color space.

The purpose of the constant background converting back and forth between two tone curves, sRGB TRC and linear gamma, is not clear at all.

At the moment it is also not clear to me. But i guess that it has to do with all the legacy code that currently is in the way, because this parts haven't been rewritten. I assume that this parts just got a wrapper (it does the color conversion, currently every time) to be able to work on the core while not making everything unusable.

But if I'm wrong and it should stay like this, then this is a real problem.

"In service of the noble goal" doesn't explain *why* the conversions are done over and over again instead of just once. I really, really, really want to know why those relentlessly repeating background conversions between sRGB TRC and linear gamma are happening. But I will stop asking. And maybe some kind soul will send a private email giving an explanation that I can understand.

In the case I'm not lier than i have given the explanation above.

I was excited to find out that the latest LCMS can do color conversions involving negative floating point numbers. If the Gimp code is only 20% finished, then perhaps the information I just gave about the new ability of LCMS to do conversions involving negative floating point numbers might be pertinent to crafting the remaining 80%. But if not, then I apologize for posting it.

Elle

Lets see what the developers have in mind. If they do it right, then there should be two solutions with the empowered to choose which one he likes, because both have a distinct advantage and disadvantage:

A) The buffer of any type / color space will be converted at load/creation time to linear RGB float. Anything else works only with linear RGB float. Final output will be converted to sRGB or device color profile.

B) The buffer will be loaded and stored in native/original format. Every access to the buffer which is not linear RGB float will force a conversion, which might need caching for better speedup. The core still works entirely in linear RGB float. and the final output will be converted to sRGB or device color profile.

While (A) would be fast it is very memory intensive for larger images. The method (B) might be very slow in comparison, but it needs much less memory.

Ideally the user would load layers/buffers and would have the choice to convert the buffer to any color space/format he likes, with the hint that linear RGB float is the fastest that does not need any conversion. So the user would have to option if he wants speed or less memory consumption.

But maybe someone wants to enlighten me that both things are not mutually exclusive.

Tobias

Elle Stone (l.elle.stone@gmail.com) wrote:

The purpose of the constant background converting back and forth between two tone curves, sRGB TRC and linear gamma, is not clear at all.

Well, it is not on purpose. It is basically a side-effect of trying to port Gimp to the new infrastructure without e.g. changing the visual output of e.g. layer modes, while avoiding changing the math (Or do it in an incremental manner while keeping the results consistent).

"In service of the noble goal" doesn't explain *why* the conversions are done over and over again instead of just once. I really, really, really want to know why those relentlessly repeating background conversions between sRGB TRC and linear gamma are happening.

Ok, for an example have a look at gimp/app/operations and grep the string "R'G'B'".

As you can see, a lot of them are designed to work in a R'G'B' mode, since this was the working assumption in our old 8 bit core. We need as-identical-as-possible results and the easiest way to port them to GEGL and adding support for the high-bit-depth modes is to let the operations work in "R'G'B'A float" and port the math in the most straightforward way possible.

Now every time some of these operations is involved, the GEGL core needs to convert the "RGBA u16" data as stored in the image to "R'G'B'A float" so that the operation can properly work in its expected working format. And of course before the new data ends up in the pixel storage it needs conversion back to "RGBA u16".

Of course this is not good and has a massive speed impact, ideally the operation should be able to work on "RGBA u16" directly, but then the math becomes nontrivial (we need compatible results). This is optimization work that we have not even really started tackeling.

I fully expect to have other problems like this on all kinds of different places and I don't know which of these point it actually is you're hitting with your test cases.

With your "elimination" of the conversion in util.h you probably have introduced visually different results for these kind of operations (because e.g. the "addition" mode now adds up in a linear fashion, while it earlier worked in Gamma mode). Of course it is debatable how certain layer modes are supposed to work, but we also need to maintain some backwards compatibility, so that old XCF files in a new Gimp look the same as always.

But I
will stop asking. And maybe some kind soul will send a private email giving an explanation that I can understand.

Please not, keep it on the list. These things are tricky and they deserve to be pulled into the open :)

And don't stop asking.

Bye, Simon

On 31 August 2012 17:37, Elle Stone wrote:

On 8/30/12, Jon Nordby wrote:

This is actually one more conversion and one step earlier than we need to. Ideally the pipeline should look like this:

GeglBuffer -> | display filter stack | -> sRGB in monitor profile -> | Cairo |

That way we only convert to the monitor profile as a last step. This would require GEGLifying the display filter stack and all the modules it uses.

(I think "sRGB in monitor profile" probably means "sRGB or monitor profile". Jon - yes? no?)

Yes.

El 31/08/12 14:05, Simon Budig escribi:

With your "elimination" of the conversion in util.h you probably have introduced visually different results for these kind of operations (because e.g. the "addition" mode now adds up in a linear fashion, while it earlier worked in Gamma mode). Of course it is debatable how certain layer modes are supposed to work, but we also need to maintain some backwards compatibility, so that old XCF files in a new Gimp look the same as always.

I can only speak as a user, and I'm not sure about how other users feel about this, but even after 6 years of GIMP as my main and only bitmap manipulation software, I wonder how much of a big deal would be to ditch legacy appearance.
Of course several of my old files will look different, but if I think of it as a compromise to get a better GIMP, I'm all for it. If I had to modify old files to make them look right in linear blending, it wouldn't be very difficult, and for those cases when getting the same results is critical, I still could use GIMP 2.8 Keeping legacy seems like an anchor for any program, and I wonder if keeping a legacy version as a separate product wouldn't make more sense than leashing the power of GIMP could have and squeezing dev's brains and time to get legacy co-existing with the new core. I also wonder how much of GIMP's userbase uses it for complex composites with lots of layers and blending modes. Judging by the forums and tutorials out there, probably most of the users wouldn't notice if sRGB blending is replaced by linear.

There is a special case, though, that I wanted to leave for the end: Using GIMP for web mockups. Web browsers still use gamma blending for compositing RGBA images (a png with transparent background, for instance). It's true that creating mockups in linear space would give different results, but that could be solved by adding a special variant of the "normal" blending (simple porter-duff alpha-over op) that gamma-corrects both inputs, composites them and then linearizes the result. And maybe it doesn't have to be a special blending mode but a preview mode ("web preview" or something like that") that creates a projection with every alpha-over done in gamma-corrected space.

Anyway, that seems to be something that can be addressed later.

I'm curious to know how other users feel about this. I'd even suggest to comment everything legacy out in 2.10 and see how user community reacts. If it's too bad for the majority of the users out there, GIMP 2.8 would be still an option (I mean, if there are users who chose to stick with 2.6 because of the save/export thing, they can stick with 2.8 because of legacy looks). If nobody cares, happy-happy, joy-joy. :-)

Gez.

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Guillermo Espertino (Gez) (gespertino@gmail.com) wrote:

El 31/08/12 14:05, Simon Budig escribi:

[compromises in Gimp] so that old XCF files in a new Gimp look the same as always.

I wonder how much of a big deal would be to ditch legacy appearance.

Well, it is not just about compatibility, it is also about trust of our userbase.

I think it is important that we do not give the impression that we mess around with the users data at the whim of the developers. Some people probably have invested lots of time in complex artwork where it is not exactly clear what to do to restore the original look, especially if you don't know where to steer towards.

Anyway, it probably is not that bad. We already discussed the possibility of legacy layer modes which would retain the old look but are basically unavailable or hidden in the layers dialog.

At the same time new layer modes with the old names can be introduced.

Bye, Simon

simon@budig.de              http://simon.budig.de/
_______________________________________________
gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Fri, Aug 31, 2012 at 11:12 PM, Simon Budig wrote:

At the same time new layer modes with the old names can be introduced.

Or you could rename old ones to "foobar-old" and just use "foobar" for the new ones.

Alexandre Prokoudine http://libregraphicsworld.org

El 31/08/12 16:12, Simon Budig escribi:

Well, it is not just about compatibility, it is also about trust of our userbase.

My question is:
a) Does the existing userbase actually care about it? b) Wouldn't doing a relevant change like that, but communicating it properly wouldn't be enough to avoid problems and keep users happy? (if such thing is possible :p)

GIMP has many users, but if you look for artists or designers using it for complex artwork the list is rather short, and probably that kind of artists will prefer linear blending because it does look better (just place a blurred gray circle on a magenta background in gamma and linear spaces and ask people which looks better, I bet no one will choose gamma).

I think it's about communication. If GIMP ditches gamma blending, but every time you open an old file you get a notice saying that layer modes appearance might change, and it is documented clearly that this change was made for the better, I doubt anyone will feel betrayed by developers.

And if there's a strategy to "bake" the old look into a layered or flattened image, then nobody will complain. I'm asking some friends about this, and everyone seems to be fine with an importer that warns about the appearance chance and offers the alternative of baking the appearance losing some editability. I'm not saying that asking a few friends is enough, but I'd really like to know how other users feel about this.

I think it is important that we do not give the impression that we mess around with the users data at the whim of the developers. Some people probably have invested lots of time in complex artwork where it is not exactly clear what to do to restore the original look, especially if you don't know where to steer towards.

I think it's about communication. If GIMP ditches gamma blending, but every time you open an old file you get a notice saying that layer modes appearance might change, and if it is documented stating clearly that this change was made for the better, I doubt anyone will feel betrayed by developers.

It's like saying: "this is the right way to do it. Our old core didn't let us do it this way, but now we can. Now composites will look as they should, but perhaps that means that what you created with an old version will now look a little different".

And if there's a strategy to "bake" the old look into a layered or flattened image, then nobody will complain. I'm asking some friends about this, and everyone seems to be fine with an importer that warns about the appearance chance and offers the alternative of baking the appearance losing some editability. I'm not saying that asking a few friends is enough. I'd really like to know how other users feel about this.

Anyway, I wouldn't be so worried about users feeling betrayed. Users do that.
A lot of them felt the save/export separation as a betrayal and even some of them claim that they won't be using GIMP anymore because of that. Some people even complains about the bulky look of the new sliders. Some people even complains about the no-image window introduced in 2.6 saying the floating toolbox with a menu was better!

Anyway, it probably is not that bad. We already discussed the possibility of legacy layer modes which would retain the old look but are basically unavailable or hidden in the layers dialog.

At the same time new layer modes with the old names can be introduced.

I wonder what's the real benefit of doing such thing. Ok, old files will be still functional and users will be able to work with them. But at the same time it introduces complexity and odd behavior of the application. For instance, a user may ask why the overlay mode works in that way in his old files but not with the new files. If that happens, the user will go to the forums, lists or IRC and ask. Somebody will have to answer why. Somebody will have to answer why untagged 8bpc images and, say AdobeRGB 8bpc images look different when blended. It will also mean that some users will create new files from scratch and then say "I want to use the legacy-normal mode, why can't I do that?". Keeping legacy visible will clutter the UI. Hiding it will mean more people asking where is it.

It sounds either like a mess or like a lot of hard work to make those situations co-exist, and the benefit is still only for the few guys that need to open an overly complicated composition made with an old GIMP to modify it, keeping the old look.
I'd prefer that all that effort is put on making GIMP a more powerful application and I bet that keeping legacy is a huge PITA for developers and it's far more interesting and fun to add new features and streamlining the application.

BTW, all this legacy stuff seems to go against the product vision. Making a tool for a specific audience means some compromises, and this is certainly a compromise that "high-end image manipulation" audience wouldn't mind.

Gez

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Am Freitag, 31. August 2012, 22:16:50 schrub Guillermo Espertino (Gez):

[...]

BTW, all this legacy stuff seems to go against the product vision. Making a tool for a specific audience means some compromises, and this is certainly a compromise that "high-end image manipulation" audience wouldn't mind.

Especially these people will be upset if their older work can't be opened and edited any longer. It's not the kiddies doing animated sigantures for web forums that the developers care about, it's the serious users which are the target in the product vision. And having several versions of GIMP installed in parallel is no option for them. I guess you are beating a dead horse here.

Gez

Tobias

El 31/08/12 17:46, Tobias Ellinghaus escribi:

BTW, all this legacy stuff seems to go against the product vision. Making a tool for a specific audience means some compromises, and this is certainly a compromise that "high-end image manipulation" audience wouldn't mind.

Especially these people will be upset if their older work can't be opened and edited any longer. It's not the kiddies doing animated sigantures for web forums that the developers care about, it's the serious users which are the target in the product vision. And having several versions of GIMP installed in parallel is no option for them. I guess you are beating a dead horse here.

Nobody said that it wouldn't be possible to open or edit old files. The problem here is appearance.
If you open a layerer composite in linear space it will look different than the same composite blended in gamma space. Some blending modes look almost the same, some of them don't. It also depends on the image. The effects of linear compositing would be more visible in some cases and almos unnoticeable in others. So, what I proposed was just using linear space for blending for everything (including old files) and offering an optional projection or "bake" mode for keeping the old appearance as close as possible. And that can come later.
It seems pointless to keep legacy code to take care of the old stuff and complicate things just to be able to manage a handful of old files.

I think I can consider myself a high end GIMP user and not a kiddy doing animated signatures. I'm discussing about making GIMP a high end tool, which probably involves in some point getting rid of the low-end legacy. It's a compromise, sure. But nothing keeps GIMP from getting a mechanism for importing and displaying legacy files later, on top of a sane and high-end pipeline.

Gez.

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list