Removing an 'edge glow'

[John King]

You're welcome, Rex.

Every kind of image is just a data file, either in raw format or as a recognisable image file (.JPG, .TIF, etc).

Regardless of what file type, each colour pixel in the Bayer array is represented by a bit value in the resulting file. In an 8 bit processed file (e.g. an out of camera .JPG), that means that each pixel can have one of 256 values (2^8 = 0-255). In a 16 bit file (colour space), each pixel can have one of 65,536 values (2^16 = 0-65,535). This means that moving a colour value by one bit value has far less impact on a 16 bit file than on an 8 bit file (this is grossly and crassly simplified, but the point made is still correct).

Many cameras also use 12 bits to represent raw file values, some use fewer bits, some use lossy compression, some use 14 or 16 bits (medium format cameras usually use 16 bit raw files).

Regardless, when the raw file is converted into an image file, the bit values are mapped into either an 8 bit colour space - irrecoverably crunched/flattened/lost data - or expanded into a 16 bit colour number. The latter preserves far more data than using an 8 bit editing workflow.

A 12 bit raw file contains 2^12 = 4096 values for each of the four channels - each part of a Bayer array is made up of 4 pixels - a red, two different greens and a blue pixel, usually represented as RGBG, but there are some really weird colour filter arrays out there! My 2003 Nikon Coolpix 5000 used CMYG, or similar.

More possible bit values for a given pixel translates into more editing latitude and better colour differentiation, more subtle editing is usually the result.

The colour space determines how large a colour gamut these numbers can represent.

Always remember that you can always compress the bit depth of a file, but you cannot expand it! The same goes for wide to narrow colour spaces.

In practical terms, an 8 bit sRGB .JPG generated from a 16 bit aRGB colour space raw will look much better than an OoC sRGB JPG - trust me!

[gcflora]

In an 8 bit processed file (e.g. an out of camera .JPG), that means that each pixel can have one of 256 values (2^8 = 0-255).

Hmm.. typo? 8 bit formats (like colour JPEG) use 8 bits per channel (8 bits each for red, green and blue). So the maximum number of colours a pixel can have (i.e. the bit depth) in a colour JPEG is 2^(8*3) = 2^24 = 16777216. (https://en.wikipedia.org/wiki/JPEG#Encoding)

Looking at the source code for ImageMagick it looks like 12-bit (per channel) JPEGS are at least possible -- it checks for > 8 bits per channel and outputs an error if > 8 is specified by the file. I've never encountered a JPEG with 12 bits per channel so maybe ImageMagick has the check just as standard programming practice... dunno, it just seem odd that the error message is "12-bit JPEG not supported" [1]. Unfortunately the JPEG standard (ISO/IEC 10918) is not free so I cannot check. T.871 (05/11) and T.872 (06/12) are available but they're about the closely related JFIF and only mention 1 or 3 channels and 8 bits per colour channel support ("The encoded image in the JPEG File Interchange Format shall have 1 or 3 colour channels and 8 bits per colour channel.") Anyway, the 1 channel version is for greyscale (256 shades).

Edit [1]: After looking more closely that might be there for TIFF files using JPEG compression, not for JPEG files per se. At any rate 256 colour greyscale or 24-bit colour is standard for JPEG. Reading through stuff at https://github.com/LuaDist/libjpeg suggests that 24-bit is normal (e.g. phrases such as "JPEG's 24-bit output") for storage. Interestingly that library plans to add support for reducing colour precision, (e.g. 24-bit to 15-bit) but this is post-processing after the 24-bit JPEG data is read.