Natterer: Goat Invasion in GIMP

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

>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.

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.

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.

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.

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!

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.