User: Password:
|
|
Subscribe / Log in / New account

Natterer: Goat Invasion in GIMP

On his blog, Michael Natterer writes about some major progress in making GIMP work with the Generic Graphics Library (GEGL), which will allow GIMP to handle images with more than 8-bits-per-channel among other things. "About 5 weeks ago, I happened to pick up Øyvind Kolås, aka Pippin the Goatkeeper to stay at my place for about a week and do some hacking. After one day, without intending it, we started to do some small GEGL hacking in GIMP, just in order to verify an approach that seemed a good migration [strategy] for the future porting. [...] What was planned as a one week visit turned into 3 weeks of GEGL porting madness. At the time this article is written, about 90% of the GIMP application’s core are ported to GEGL, and the only thing really missing are GeglOperations for all layer modes."
(Log in to post comments)

Using GIMP without losing colour depth

Posted Apr 17, 2012 18:39 UTC (Tue) by epa (subscriber, #39769) [Link]

This is really good news. I think it means I'll try out the GIMP for photo editing tasks. Until now, I've been afraid that even if there is some high-bit-depth support with GEGL, clicking on the wrong operation might reduce the image to 24-bit RGB without warning. Or is that fear groundless in any case?

Using GIMP without losing colour depth

Posted Apr 17, 2012 19:07 UTC (Tue) by Sho (subscriber, #8956) [Link]

You might also want to give Krita a try some time. Calligra 2.4 was released a couple of days ago, and the Krita developers now consider the application stable and ready for professional use (which they don't say lightly, since they've involved professional artists in their development process for some years now, and e.g. work heavily with the Blender open movie team).

Now, Krita actually doesn't consider photo manipulation one of their major use cases, but rather focusses on painting and illustration. However, there's a lot of tool overlap between the two in practice, and Krita has a very modern foundation with support for a vast amount of colorspaces and colorspace-independent tool implementations. It even does L*a*b.

Using GIMP without losing colour depth

Posted Apr 17, 2012 20:21 UTC (Tue) by boudewijn (subscriber, #14185) [Link]

We took a long time to release Krita 2.4 -- it was already reviewed here at LWN: http://lwn.net/Articles/464495/.

Still, we did beat GIMP 2.8, probably by no more than a nose-hair's length, I think that GIMP 2.8 is now only waiting for a splash screen...

But, yeah, Krita 2.4 is awesome :-). We're so proud. Check http://www.valdyas.org/~boud/about-krita-2-4.zip for a nice PDF with all the details and a bunch of screenshots with great artwork.

Using GIMP without losing colour depth

Posted Apr 17, 2012 23:08 UTC (Tue) by jiu (guest, #57673) [Link]

Seriously? a 32MB 'about Krita' pdf? Could have compressed whatever is in there (I still don't know, 2min left to finish downloading).

Using GIMP without losing colour depth

Posted Apr 17, 2012 23:13 UTC (Tue) by Sho (subscriber, #8956) [Link]

It's not just a PDF, there's a separate set of screenshots as well. The PDF is only 11 MB.

Using GIMP without losing colour depth

Posted Apr 18, 2012 3:55 UTC (Wed) by jiu (guest, #57673) [Link]

... and, to be honest, the artwork was worth the wait! I was already a bit of a fan of David Revoy from seeing his Blender productions, this is also very nice.

Using GIMP without losing colour depth

Posted Apr 17, 2012 19:51 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link]

As I understand it, one of the major points of GEGL is that it is able to apply changes nondestructively, so you'll only be at risk of irreversibly converting your data to 8-bit/channel when you flatten it for export. IIRC, this is supported by a major change in GIMP behavior: in 2.8, GIMP will only save files in its own format, with other formats requiring an explicit export step.

Using GIMP without losing colour depth

Posted Apr 17, 2012 23:42 UTC (Tue) by zlynx (subscriber, #2285) [Link]

But is there any risk that running a plugin will read 24-bits per channel data, convert it to 8 per, run the plugin operation and write it back as 8 per?

Using GIMP without losing colour depth

Posted Apr 18, 2012 3:46 UTC (Wed) by PaulWay (subscriber, #45600) [Link]

Unless you're dealing with images that are far beyond the needs of mortals, I suspect you mean 24-bit images (usually 8-bit RGB) rather than 24-bits-per-channel.

Mind you, I suspect that you could still get 'photophile' photographers to buy a camera that claimed a 2^72 point colour space and 2^24 alpha levels. It'd go beside the $2400/meter oxygen-free monodirectional pure copper stereo cables (http://www.dontgoto.stereotimes.com/cable110107.shtml) and the purple hologram bracelet to "improve your energy" (http://www.alsodontlookat.myimprovebalance.com/our-balanc...).

Have fun,

Paul

Using GIMP without losing colour depth

Posted Apr 18, 2012 4:41 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

>Unless you're dealing with images that are far beyond the needs of mortals, I suspect you mean 24-bit images (usually 8-bit RGB) rather than 24-bits-per-channel.

No. He means EXACTLY images with 16-24 bits per channel.

And please, stop scoffing.

While 16 bits per channel is indeed a much bigger dynamic range than you can see (never mind display) at once, higher dynamic range allows you to increase contrast without visually losing information.

That comes in VERY handy when you need, for example, to make photos in the dark with some bright objects present. That allows to achieve HDR-like effects using a single image: http://en.wikipedia.org/wiki/High_dynamic_range_imaging#E... - something like this.

Using GIMP without losing colour depth

Posted Apr 18, 2012 14:26 UTC (Wed) by gmaxwell (guest, #30048) [Link]

Uh. The eye's instant dynamic range is more like 12bits in luma. We get by with 8 bits because the nonlinear response puts the noise where its least noticeable. But 8 bpc still obviously bands— 10bpc nonlinear is a big improvement and it's really unfortunate that there is ~no progress in the direction of supporting this in the free software world.

Considering long term adaptation human vision has more like 20 bits of luminance dynamic range.

Using GIMP without losing colour depth

Posted Apr 18, 2012 4:57 UTC (Wed) by Imroy (guest, #62286) [Link]

1. Yes, many digital cameras produce RAW files with greater than 8 bits per component. And many scanners (especially dedicated film scanners) produce images with greater than 8 bits per component.

2. Wide colour gamuts, as used by many cameras and scanners, require greater bit depths to avoid posterization.

3. If you're going to be manipulating an image, being limited to 8 bit components risks posterization e.g when adjusting brightness/contrast/curves. Even if your source is only 24-bit, you should still use greater depth when manipulating them (in memory or temporary files on disk). We are, after all, talking about an image editor here.

Using GIMP without losing colour depth

Posted Apr 18, 2012 5:00 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

I've never heard of 24 bits per channel, but 16 bits per channel is what most photographers would like to use these days, and 32 bit floating point per channel seems to be common for HDR images. While 8 bits per channel with a gamma curve may be fine for display purposes, it's not good enough for editing. Applying a strong contrast correction to 8 bit per channel data will result in really ugly posterization or (if you try to correct for it) obvious dithering. You want more bits of color depth than your capture device can provide so any round-off errors will be of noise rather than signal.

Floating point

Posted Apr 18, 2012 9:23 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

In the audio chain we see 24-bit recordings (for headroom) processed in 32-bit single precision floating point and then mixed down to 16-bit for publication (e.g. CDs)

The rough equivalent in video / photography would be 16-bit raw images (again for headroom) processed to 16-bit half precision floating point (almost the same precision as 12-bit integer but far larger range) with 8-bit published image data. However although GPUs often accelerated halfs, most CPUs do not so far as I know, and so GIMP's native operations would be hamstrung on most computers if it used half precision as its internal representation. That might argue for using 32-bit floats even though they're probably overkill.

Using GIMP without losing colour depth

Posted Apr 18, 2012 9:54 UTC (Wed) by farnz (subscriber, #17727) [Link]

No, he probably does mean 24 bits per channel. While the human eye can't see the graduations at that depth, processing signals (whether images or sounds) accumulates artifacts in the least significant bits.

By using an insanely high bit depth during editing, you can ensure that the processing artifacts are all in the bit of the signal you're going to discard for final output (at typically 12 bits per channel for cinema, 8 bits per channel for computers or TV).

For much the same reason, pro audio work typically starts with a 24 bit sample (where the bottom 2-4 bits are typically noise from the ADC process), works with 32 bit floats, and downsamples to 16 bit for final output.

Using GIMP without losing colour depth

Posted Apr 18, 2012 17:56 UTC (Wed) by lenov (guest, #15428) [Link]

This whole thread suggests that image treatment software are only for processing images aimed at human eyes. High quality CCD used in scientific research record very high dynamics. Having 65536 levels of intensity is very different from having 256 when analysing signals. This is why you will find 100% of biologists using Photoshop, even when, like me, they use Linux and The Gimp for presentations etc.

Using GIMP without losing colour depth

Posted Apr 20, 2012 21:50 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link]

If you want more bits while sticking to FOSS, you could try Cinepaint instead of GIMP. It handles color in 16 bit per channel linear and 32 bit per channel floating point formats. It's mostly aimed at the movie industry, but it should work OK for other images that need higher precision.

Using GIMP without losing colour depth

Posted Apr 22, 2012 20:17 UTC (Sun) by jospoortvliet (subscriber, #33164) [Link]

in that case i would rather go krita. While, like cinepaint, krita is not aiming for image editing but rather creating, that seems closer to the purpose of GIMP than cinepaint aiming at movie stuff. I would however try both as have no experience with cinepaint..

Using GIMP without losing colour depth

Posted Apr 18, 2012 5:03 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

Reading the article, it sounds as if plugins will have to be rewritten to take advantage of GEGL or you'll see exactly the kind of flattening of high bit depth images you're worried about. The good news is that it sounds as if porting them shouldn't be too hard.

Using GIMP without losing colour depth

Posted Apr 18, 2012 9:44 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

It's not clear whether it can happen by accident though. In GIMP traditionally a plugin registers itself according to which pixel formats it can process. A plugin which doesn't make sense on RGB data (e.g. it does some operation on image palettes) is then not directly available to be used until you convert the image to a form where that plugin does make sense. So you can't accidentally make your photograph into a palette based image without realising that's what will happen. Previously plugins which save image data would offer to create a copy of the image and convert that if necessary (e.g. if you save your photograph as a GIF) rather than damage the original. I believe GIMP now forces users to "export" images to all formats other than its own native format, making this more explicit.

If the new GEGL integration just adds to the list of pixel formats then options provided by today's plugins will just be greyed out signalling that you can only use them after converting down to 8 bits per channel. I seem to remember that the popular Photoshop application initially had very few plugins capable of high bitdepth operation and so whole menus would be entirely grey.

On the other hand if GEGL automatically converts then indeed the user will lose all their extra precision the first time they perform an operation implemented by a legacy plugin. That would reduce the user education problem ("Why is plugin X greyed out?") but might hurt confidence in GIMP's data integrity.

Using GIMP without losing colour depth

Posted May 8, 2012 9:19 UTC (Tue) by prokoudine (guest, #41788) [Link]

You are basically asking, what if someone uses a plugin that hasn;t been ported to GEGL yet. The plans is to get rid of such plugins in the bundle and encourage 3rd party developers to port their stuff to GEGL too.

Natterer: Goat Invasion in GIMP

Posted Apr 18, 2012 3:16 UTC (Wed) by slashdot (guest, #22014) [Link]

Interestingly, GEGL claims to support floating point color and optional OpenCL acceleration, so it seems it's actually modern and even better than it looks from the article and abstract.

I guess the next frontiers to have could be:
- Per-component alpha
- Arbitrary sample locations instead of regular grid
- Explicit image reconstruction filters, and scaling etc. respecting them
- Arbitrary number of color and alpha components (with arbitrary spectral base functions and multiple "layers")
- Double precision, arbitrary precision and unlimited precision numbers for image components
- Support for Z components in arbitrary sample locations and dense 3D regular grid images, and extensions of all operations where it makes sense from 2D to 3D
- Maybe some explicit notion of displacement, normal and BxDF parameter (e.g. specular power) components, although I'm not sure it would make sense

Natterer: Goat Invasion in GIMP

Posted Apr 18, 2012 11:17 UTC (Wed) by dgm (subscriber, #49227) [Link]

> - Per-component alpha

I'm having a hard time trying to figure out what that means, and what could it be useful to. It's not a colored glass effect, because for that RGBA is enough. What then?

Natterer: Goat Invasion in GIMP

Posted Apr 18, 2012 14:13 UTC (Wed) by slashdot (guest, #22014) [Link]

An alpha value for each component (red alpha, green alpha, blue alpha), which in other words allows to specify the transparency/amount of transmitted light for red, green and blue light separately.

No, RGBA is not enough for colored glass.

Natterer: Goat Invasion in GIMP

Posted Apr 18, 2012 15:13 UTC (Wed) by mikachu (guest, #5333) [Link]

nor is per-component alpha, you want per-wavelength alpha which would take quite a few more bits to encode :).

Physics versus perception...

Posted Apr 19, 2012 21:14 UTC (Thu) by Pc5Y9sbv (guest, #41328) [Link]

That's right, it is fun to make a per-channel alpha blender and play with it (you can simulate in OpenGL by doing one pass per channel with a channel mask). However, it is just a weird trick that doesn't get you closer to physics, and doesn't do anything particularly intuitive with respect to computed color spaces.

Because our digital color systems encode perceived color and brightness rather than spectral energy distribution, you cannot model things like selective absorption or re-emission, the basis of real-world pigments and filters. While you might think it works after thinking about the simplistic "red glass" filter, it doesn't really work for different lights and glasses we would perceive as red but which are really mixtures of different wavelengths.

Think of each pixel as a 2D curve of energy over wavelength at this point in the image plane, representing the entire cone of space behind it. Instead of a multi-channel blending function, you would have a transfer function that changes the arriving 2D curve into another 2D curve. However, some light sources and pigments often have very narrow emission lines or notch-filtering behaviors, best represented as some sort of variable set of discrete wavelength intervals, while other black-body kinds of radiator have broad spectra best represented as a smoothed curve. Any lossy compression scheme would likely destroy the physical properties you are trying to simulate, unless tailored for the specific lights/materials/effects at play along the light path.

A more likely physical simulation approach would be something like monte carlo sampled ray-tracing or photon-mapping, reevaluating the scene with a large number of discrete wavelength-energy bundles, giving you some dithered and accumulated final result in the image plane. As an added benefit, things like refraction would really work right, so you could shine a white light through a prism and get a rainbow out the other side, based on the different wavelength-specific interactions of each sample with the materials in the scene.

The conversion from spectral energy into perceived color would have to be delayed until the final accumulated spectral energy plot is available at the image plane. You could imagine either a framebuffer with a 2D curve at each pixel, or perhaps a stack of hundreds or thousands of monochromatic layers each representing one sampled wavelength. Things like absorption and re-emission at different wavelengths would add complication, since a particular "ray" could change wavelength as it traverses the scene.

Of course, given all that, we might still wonder why we cannot simulate polarizing filters, iridescence of nanostructures, or constructive/destructive interference of light... that would require an even more complex framebuffer!

Physics versus perception...

Posted Apr 20, 2012 6:23 UTC (Fri) by boudewijn (subscriber, #14185) [Link]

Stuff rather like this was implemented for Krita a couple of years ago. It has fallen into disrepair when the author became too busy in his student union, but was presented at the Libre Graphics Meeting in Wroclaw in 2008.

Right now, it still compiles, but its practical utility is very limited since the color mixing tool is broken.

Physics versus perception...

Posted Apr 20, 2012 11:19 UTC (Fri) by dgm (subscriber, #49227) [Link]

Please, do not forget we are not discussing Blender or POV-Ray. It's the GIMP what we are talking about.

Physics versus perception...

Posted Apr 20, 2012 12:00 UTC (Fri) by boudewijn (subscriber, #14185) [Link]

Have wave-length based color models would still be fun for gimp, and could be done with gegl and babl.

Physics versus perception...

Posted Apr 20, 2012 16:05 UTC (Fri) by Pc5Y9sbv (guest, #41328) [Link]

Fair enough, here's a condensed version ignoring 3D and focusing on image manipulation...

You can experiment with per-channel alpha in GIMP today, splitting your multi-channel layer stack into monochromatic layer stacks and applying per-channel alpha masks on each layer before compositing them back into RGB.

While this RaGaBa approach can help one understand RGBA and its limits, it doesn't get you closer to real color mixing/filtering phenomena. It doesn't free you to get more correct/accurate color mixing without having to think about the limits of color spaces and color rendering; rather, it gives you another digital medium with which you have to make hard interpretive decisions that don't translate well to other media. It's a bit like giving an oil painter a different set of paints, which behave slightly differently when mixed, so he'll have to learn how to use them all over again in order to produce scenes he imagines.

Also, consider scientific imaging which often has broad spectral information, e.g. taken with a monochromatic sensor with a color filter wheel or variable wavelength light source. There are many GIMP-related image processing tasks someone might want to perform when preparing such image sets to make final print or web images, whether false-colored or true-to-life. A real spectral-energy pixel and blending system would provide much more meaningful tools for this kind of work.

Natterer: Goat Invasion in GIMP

Posted Apr 18, 2012 21:48 UTC (Wed) by dgm (subscriber, #49227) [Link]

Pixels are not materials. I cannot think any reason to have different transmissive and reflective colors in a single pixel, as it is either transmitting and tinting the pixel behind, or it is not, and thus the color behind does not show at all.

So, what I'm missing?

Natterer: Goat Invasion in GIMP

Posted Apr 18, 2012 23:38 UTC (Wed) by SEMW (subscriber, #52697) [Link]

Unless I'm misunderstanding something, why isn't the coloured glass that's already been referred to motivation enough? It's clearly not possible, using RGBA, to have a pixel that transmits the red channel of the pixel behind it but blocks the blue and green channels, which is what (ideal) red coloured glass does.

Natterer: Goat Invasion in GIMP

Posted Apr 19, 2012 0:49 UTC (Thu) by dgm (subscriber, #49227) [Link]

> It's clearly not possible

Have you tried it? I have done a quick test in the GIMP and RGBA gets exactly the desired result.

Natterer: Goat Invasion in GIMP

Posted Apr 19, 2012 1:53 UTC (Thu) by slashdot (guest, #22014) [Link]

Not with regular alpha blending, you need two layers where one is set to multiply the layer below.

Anyway, I guess the most practically useful case is colored text with subpixel antialiasing, where you need the regular RGB components for the text color, and per-component alpha for subpixel antialiasing.

Natterer: Goat Invasion in GIMP

Posted Apr 19, 2012 8:15 UTC (Thu) by alankila (guest, #47141) [Link]

And such blending should be done in linear light (gamma = 1.0). I always mention just to spread awareness about how the process is supposed to work, in the hope that one day I will see it happen.

When freetype gives you a 8-bit transmittivity value of, say, 128 it means that the glyph has geometry that covers ~50 % of that pixel. To correctly represent this on the screen means that you must now calculate what the screen light flux is from the background of the text (take that pixel's sRGB value and correct it to linear light color space), and then from the color used to render the font (again, sRGB to linear), then blend those light fluxes (in the 50 % case you will average them), and then transform the result back to sRGB color space (linear to sRGB), so that the monitor will take that sRGB value and transform it back to light flux.

Also because we don't want the text to come out colored, we must distribute the (subpixel) light flux to three nearby components, but this can be by using a 3-tap boxcar FIR that spreads the linear light intensity value of the source font data between the neighboring components, ensuring that they will be evenly activated.

Unfortunately, this process is complicated enough that there does not appear to be any software on linux that gets it right. As a simple example, people think that average between black and white is (0x00 + 0xff) / 2 = 0x7f. But because of gamma, the actual brightness average is closer to 0xba.

I have a demo of the stuff here: http://bel.fi/~alankila/lcd/ and some screenshots for how it looks for me. I've seen that the demo doesn't even look good on all linux systems for some reason, though. (I disable all hinting usually, which helps with generating the font shapes for this process.)

Natterer: Goat Invasion in GIMP

Posted Apr 19, 2012 9:58 UTC (Thu) by dgm (subscriber, #49227) [Link]

> Not with regular alpha blending, you need two layers where one is set to multiply the layer below.

That would be exactly the same with per-component alpha, wouldn't it?.

> Anyway, I guess the most practically useful case is colored text with subpixel antialiasing, where you need the regular RGB components for the text color, and per-component alpha for subpixel antialiasing.

Well, that at least makes sense. But only because you're dealing with subpixels in the particular case of font rendering (or maybe line drawing) for an RGB display. I'm still not convinced that it is all that necessary for the GIMP, though, given that the results would look ugly in a non-RGB display (printed on paper, for example).

Colored alpha...

Posted Apr 20, 2012 18:13 UTC (Fri) by Pc5Y9sbv (guest, #41328) [Link]

I've seen several students go through this thought process of wanting "colored alpha blending", specifically thinking about things like colored glass, and so I assumed this is what people were seeking here too. The recurring idea was that a transparent mask could "permit red to pass but block other colors", or "block red but permit other colors" by having different per-channel alphas.

The problem, of course, lies in the implicit desire that such a mask could also filter other colors, e.g. "permit yellow to pass" or "block yellow" by having a yellow or purple alpha color. Sadly, a per-channel alpha blend configured to pass yellow would also let lots of other colors pass, just mangling them by removing their blue component. The seemingly intuitive alpha blending model invites this naive expectation, because the student has not really understood the real multiplicative blend that is occurring. They often just see the other blending modes as frustrating and useless, rather than seeing the equivalence!

Unfortunately, such selective filtering cannot be represented as simple blends in any color system that reduces the color space to linear combinations of primary colors. You need a spectral-energy representation for the layers and masks if you want to avoid thinking about all the color-aliasing inherent to an N-chromatic color space at every turn.

Colored alpha...

Posted Apr 21, 2012 9:13 UTC (Sat) by alankila (guest, #47141) [Link]

Sounds to me like it's shader writing time. These things are possible to do, but do not sound like something you could achieve with a texture format alone.


Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds