Thought I’d repost this here in case anyone’s missed it:
Øyvind Kolås has been a core contributor to GIMP for years, so if you want to support GIMP, please consider contributing to Øyvind Kolås is creating digital media tools | Patreon 
@Elle, this looks very much like what you’ve done with Gimp CCE, yes? I imagine you’re well aware of this project.
“…ability to do both linear and non-linear blending within one project, as well as enabling radiometrically correct/linear painting…”
What does radiometrically mean please? Just had a quick dictionary search and the most relevant phrase to photography was “measuring the intensity of radiant energy”.
(My photo PC build is coming along!)
[quote=“Unhammer, post:1, topic:3074”]Thanks to @hodefoting we have high-bit and non-destructive editing in GIMP - please consider supporting his efforts! patreon.com/pippin
[/quote]
OK, I’m confused - Pippin (Øyvind Kolås) is the lead babl/GEGL developer. But who is hodefoting?
It is his twitter alias.
@RawConvert - babl and GEGL provide the format conversions, color space conversions, and most of the editing algorithms that makes high bit depth GIMP 2.9 possible. As currently coded, hard-coded sRGB primaries and TRC in babl/GEGL/GIMP make default GIMP 2.9 not yet suitable for editing in color spaces other than sRGB. But support for “any RGB working space” is already a goal for babl/GEGL/GIMP.
GIMP-CCE is a strictly interim project for people like myself who want to use high bit depth GIMP for editing in any RGB working space “right now”. CCE is basically a “hack” that adds in support for editing in any well-behaved RGB working space by stripping away a lot of other features from the “unhacked” versions of babl/GEGL/GIMP. Even as a strictly interim project, updating CCE is increasingly difficult to do as new code is committed to regular babl/GEGL/GIMP. So a lot of new features and bug fixes that are being worked on for regular GIMP 2.9 won’t make it into CCE.
As the lead babl/GEGL developer, Pippin’s work has been crucial to the development of high bit depth GIMP and remains crucial for getting full support for editing in non-sRGB color spaces into default GIMP. So his patreon campaign is especially important if you want to see support for “any RGB working space” make it into default GIMP sooner rather than later.
Ah, thanks!
In the context of RGB image editing, “radiometrically correct” means working with RGB channel values in such a way as to emulate as closely as possible the way real light waves combine out there in the real world. This means using linear gamma RGB color spaces, at least for all the RGB editing operations that actual do have real-world counterparts to how light waves combine in the real world.
In my opinion, almost always results from editing and color mixing in linear gamma RGB color spaces are more aesthetically pleasing than results of the same operations done in a perceptually uniform RGB working space. But sometimes there are artistic reasons to “do the wrong thing”. And for some editing operations there really is no “real world” counterpart - for example posterizing an image or adding RGB noise. In these cases sometimes you might prefer results from editing using linear RGB and sometimes you might prefer results using perceptually uniform RGB.
Thanks for the replies and info.
I’ve set up a modest monthly donation.
Andrew, that is very nice of you.
Hopefully it was clear when I said “important if you want to see support for ‘any RGB working space’” that I meant “you” generically, as applied to anyone using GIMP, and not as applied to you in particular. Sometimes a little funding can go a long way to enable someone to keep writing code. But there are many other ways to contribute to free/libre software, with participation in user forums also being an important way to contribute.
1 Like
No worries, I took “you” in the wide sense! I think and hope Gimp will become a cornerstone of my photo processing, so I’m happy to contribute to what sounds like an important upgrade to the “core”. What is “high bit depth”? 32bit floating point?, 64bit?
16, 32, 64 are all “high bit depth”.
GIMP 2.8 and earlier only uses 8-bit-per-channel colour for (almost) all operations, which means you get calculation errors that “clip” colours and make it easy to lose information. 8-bit is good enough for storing and viewing images (8 bits gives 256 colours per Red, Green and Blue channel; normal monitors have no more nuance than that), but when you run e.g. two brightening filters in a row, you have a lot more “decimal places” in 16-bits than in 8-bits, so even if it’s only viewed as 8-bit, you lose a lot less information in the intermediate calculations. http://www.photoshopessentials.com/essentials/16-bit/ shows some examples of how easy it is to get banding, like unintended posterising, from running operations in low bit depth.
@Unhammer is right, anything higher than 8-bits per channel is considered “high bit depth”.
The only complication in terminology you might run into is the difference between “total number of bits from adding each channel’s bits” and “bits per channel”. Sometimes you’ll hear someone refer to an “8-bits per channel” RGB image as being a 24-bit image. Or if an 8-bit RGB image has an alpha channel (“RGBA”), it might be referred to as a 32-bit image. Or if the image is an 8-bits per channel grayscale image with an alpha channel (“YA”), it might be referred to as a 16-bit image. In these cases the person is referring to the number of 8-bit channels times the total number of channels. These aren’t high bit depth images. As @Unhammer said, “high bit depth 16-bit image” means 16 bits per channel, “high bit depth 32-bit image” means 32 bits per channel, and so forth.
At this point in time, almost always bare phrases like “16-bit image”, “32-bit processing” and so forth mean “bits per channel”, at least when the context is image editing from a user point of view. But occasionally you still will encounter cases where it’s the total number of bits that’s being referred to.
These days 16-bit image editors are common and 32-bit image editors are becoming more widely available. For example Krita has been able to work with 32-bit images (32 bits per channel) for a long time.
High bit depth babl/GEGL/GIMP 2.9/2.10 (I wrote “babl/GEGL/GIMP” because most of the algorithms exposed in the GIMP UI are actually GEGL algorithms that in turn use babl color model conversions) does all editing algorithm calculations internally using 32-bits per channel floating point. GIMP’s “Image/Precision” menu bit depth choices are just for storing the results of calculations in RAM, to accomodate lower-spec hardware. Choosing 8-bit precision does mean a cumulative loss in data, and so for workflows involving a lot of layers and/or extreme changes in tonality it’s far preferable to use at least 16-bit precision, for exactly the reasons @Unhammer mentions.
I wasn’t sure whether to post here, or to start a new topic. So I decided to post here as it’s related to the above discussion of “anyrgb” for default GIMP.
Since the middle of August, Pippin has been uploading new code into babl, laying the groundwork for eventually making it possible to use GIMP for editing in RGB working spaces other than sRGB. I spent some time reading through the new code and talking with Pippin about the new code, and from what I can tell this new code looks really, really good.
In case anyone is wondering what this means for GIMP users:
When editing an image, sometimes it’s advantageous to operate on linear RGB, and sometimes it’s advantageous to operate on perceptually uniform RGB.
For most image editors (including my patched “GIMP-CCE”), this presents two problems to users:
-
It’s up to the user to decide which is best - linear or perceptual - for any given editing operation.
-
When the user wants to switch between linear and perceptually uniform RGB, the only way to do this is by making an ICC profile conversion, which is tedious and time-consuming, and especially so in a complicated workflow with many layers.
For sRGB images, GIMP 2.9/2.10 makes it easy to switch between linear and perceptual RGB on a per-layer/per-operation (for most operations) basis. And for people who really don’t want to think about such things, the code provides good defaults.
Speaking for myself, I’ve wanted the ability to easily switch between linear and perceptually uniform RGB ever since I realized there was such a thing as “linear RGB”. Back before 2007, when I was still using Windows and PhotoShop, every time I wanted to switch between linear and perceptual RGB, I would grumble and think “Why doesn’t someone just make this easy?”. The babl/GEGL/GIMP devs have done exactly this for sRGB for GIMP 2.10, and Pippin has been laying the groundwork to make this “easy switching” possible for other RGB working spaces.
In case you are curious, Pippin has put up a post on his Patreon page with some information about the new code:
5 Likes