Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
On Fri, Aug 31, 2012 at 12:30 AM, Øyvind Kolås 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
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
On Thu, Aug 30, 2012 at 8:08 PM, Elle Stone wrote: > On 8/30/12, Øyvind Kolås 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 t
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
On 8/30/12, Øyvind Kolås 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). And many, many more people work with 16-bit images that are NOT sRGB images and DON'T use the sRGB TRC (ProPhoto, Beta, WideGamut, etc). > 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. 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? 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. 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. With increasing dismay, but still with warmest regards, Elle Stone ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
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
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
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. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Removed GEGL color management with correct Overlay mode
On Thu, 2012-08-30 at 17:12 +0400, Paul Geraskin wrote: > Wow, cool! > > And can i make by default true? To be > it always switched on... no, that would require rebuilding. > On 08/30/2012 04:45 PM, Michael Natterer wrote: > > On Thu, 2012-08-30 at 16:36 +0400, Alexandre Prokoudine wrote: > >> On Thu, Aug 30, 2012 at 4:30 PM, Paul Geraskin wrote: > >>> Hi all. > >>> > >>> In gimp 2.8.2 Gegl ColorManagement was removed (View -> Use Gegl (in the > >>> menu)). > >> It's not color management. It's just GEGL-based projection of layers. > >> > >> You can revert the change and recompile GIMP. > > No need for that. > > > > Just put the menu item back in image-menu.xml, in the installed > > files under prefix/share > > > > --mitch > > > > > > ___ > > gimp-developer-list mailing list > > gimp-developer-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > > > > > > ___ > gimp-developer-list mailing list > gimp-developer-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Removed GEGL color management with correct Overlay mode
Hi all. In gimp 2.8.2 Gegl ColorManagement was removed (View -> Use Gegl (in the menu)). And now I cannot use correct Overlay mode for Layers. Can you suggest how to get Gegl color management? I hope you remember this issue: https://bugzilla.gnome.org/show_bug.cgi?id=673501 Guys I really need Gegl color mamnagement. As I use correct Overlay mode every day. Thanks. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gaussian/Tileable blur: Choice of IIR and RLE still necessary?
On 30 August 2012 01:11, scl wrote: > Hi, > > I'm currently working out a GUI brainstorm idea for the Gaussian and > Tileable Blur dialogs. Both dialogs let the user choose between the > algorithms IIR and RLE. The documentation says, IIR is faster on > photographs, RLE faster on drawings. I've never found a difference in > computing time between these both algorithms and wondered, whether the > choice is still necessary with modern computer environments. > What do you think about it? > Sven, You are correct in the sense that some filter choices are obsolete. Most filters had not been touched in a while - and there is the compromise that at least the inner working (i.e. the API calls) stay the same throughout GIMP 2.x. However, most filters are part of the overhaul taking place in the development version of GIMP. In the case of the more used Gaussian Bluer, the work is already done, and the filter works interactively, with on-canvas live preview, just like any GIMP tool, and the algorithm selection option is gone. If you are willing to make suggestions and help improving GIMP, you are highly encouraged to have one copy of the development version working, so that you can poke around. js -><- > Thank you, > > Sven > ___ ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Gaussian/Tileable blur: Choice of IIR and RLE still necessary?
On 08/30/12 06:11, scl wrote: Hi, I'm currently working out a GUI brainstorm idea for the Gaussian and Tileable Blur dialogs. Both dialogs let the user choose between the algorithms IIR and RLE. The documentation says, IIR is faster on photographs, RLE faster on drawings. I've never found a difference in computing time between these both algorithms and wondered, whether the choice is still necessary with modern computer environments. What do you think about it? Thank you, Sven _ It would probably be useful if the doc was clearer about what ti meant by "drawings". It makes sense that RLE would be faster in block graphics where there are large areas with exactly the same colour value. If the user is "drawing" with rounded brushes with faded edges and softening things with gaussian blurs the drawing will not necessarily fit the criteria where RLE is faster. "With modern computers" argument is countered by "on modern images". As the hardware gets faster the images also get bigger ( in both x and y) . As gimp progresses to higher bit resolutions any difference may become more relevant not less. I'd suggest some timings on large photo and similar sized image half black, half white (extreme example of the block graphic case). I'm also wondering about the IIR label. I have not dug out the code but I was not aware that gaussian could be mode by IIR filter, isn't it rather a kernel ie FIR method? If it is IIR I should have a look , it may be useful in something else I'm doing. OK, a quick google reveals I'm correct, the IIR method is just an approximate method that makes the computation complexity independent of sigma. By corollary the approximation must get worse for larger blur radius. Though I don't know whether the eye will detect which is the "better", purer blur. So IIR label is fine. /gg . ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Removed GEGL color management with correct Overlay mode
Wow, cool! And can i make by default true? To be it always switched on... On 08/30/2012 04:45 PM, Michael Natterer wrote: On Thu, 2012-08-30 at 16:36 +0400, Alexandre Prokoudine wrote: On Thu, Aug 30, 2012 at 4:30 PM, Paul Geraskin wrote: Hi all. In gimp 2.8.2 Gegl ColorManagement was removed (View -> Use Gegl (in the menu)). It's not color management. It's just GEGL-based projection of layers. You can revert the change and recompile GIMP. No need for that. Just put the menu item back in image-menu.xml, in the installed files under prefix/share --mitch ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
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 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Removed GEGL color management with correct Overlay mode
On Thu, 2012-08-30 at 16:36 +0400, Alexandre Prokoudine wrote: > On Thu, Aug 30, 2012 at 4:30 PM, Paul Geraskin wrote: > > Hi all. > > > > In gimp 2.8.2 Gegl ColorManagement was removed (View -> Use Gegl (in the > > menu)). > > It's not color management. It's just GEGL-based projection of layers. > > You can revert the change and recompile GIMP. No need for that. Just put the menu item back in image-menu.xml, in the installed files under prefix/share --mitch ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
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 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
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 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Removed GEGL color management with correct Overlay mode
On Thu, Aug 30, 2012 at 4:30 PM, Paul Geraskin wrote: > Hi all. > > In gimp 2.8.2 Gegl ColorManagement was removed (View -> Use Gegl (in the > menu)). It's not color management. It's just GEGL-based projection of layers. You can revert the change and recompile GIMP. Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Removed GEGL color management with correct Overlay mode
Hi all. In gimp 2.8.2 Gegl ColorManagement was removed (View -> Use Gegl (in the menu)). And now I cannot use correct Overlay mode for Layers. Can you suggest how to get Gegl color management? I hope you remember this issue: https://bugzilla.gnome.org/show_bug.cgi?id=673501 Guys I really need Gegl color mamnagement. As I use correct Overlay mode every day. Thanks. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
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 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
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. > * 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? > > > 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. 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 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Adding WebP Support to GIMP
On Fri, Aug 24, 2012 at 9:24 PM, William Swartzendruber wrote: >> Well, I'm not so sure that from the project's point of view redoing an >> existing work is much reasonable. >> >> Could we perhaps interest you in something more urgent for the project? > > I'd really like to work on WebP. What if I were to extend the > existing plugin's export dialog with every known configuration option > under an "Advanced settings" expander? The thing is... Old file loaders/savers are to be extinct anyway. So how about writing GEGL-based WebP loader and saver? And if the professor thinks, this is not sufficient, write foundations for UI to saving options for GELG based code? Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
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 -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
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. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
