Bit Depth and Confusion

As some may know, the last post went postal.

A total count of around 37,000 views and climbing on a subject that was aimed at about 250 daily readers.

In the furor that arose, there has been a colossal depth and diversity of discussions. Some utterly positive, productive, and explanatory, and some utterly off topic, tangential, and otherwise.

There is likely much to discuss from the output.

This post focuses on one specific aspect of the last post, that, as a result of the information and insight from some of the powerful minds over at LWN, helps to clarify the grossly misunderstood area of bit depth[1].

I can only hope this doesn't erupt into a flame war. These are real world examples with real world data and now, thankfully, some real world developers speaking up and offering further insight. That interaction is a core strength of Libre software.

If there is a weakness out there, it is the result of voting up commentary that ranges from inaccurate to completely incorrect. This is not an attempt to vilify those postings, but rather shed some light onto the issue in a practical way. It is hoped that the examples found at LWN and Hacker News provide compelling evidence of the importance of bit depth to even the most casual reader.

This discussion strictly pertains to the manipulations performed on images. In particular, it seeks to dismantle the notion that high bit depth calculations are only relevant on high bit depth imaging devices. This is simply and fundamentally untrue.

This post builds upon and heavily relies on the strength of minds over at LWN, Hacker News, and some very bright developers in the Libre community. It is hoped that further input can help to flesh this issue into a far more comprehensible subject than it currently is.

Q: What is Bit Depth?

Bit depth is the amount of information used to store a color value in a color system[2]. In an RGB additive light system such as what you are likely looking at now, each component of red, green, and blue is modeled into numbers.

A common format is eight bits per channel. This yields a scale of 0-255 for each red, green, and blue component in a typical image.

Perhaps the most prevalent system is a 24 bit per pixel representation. This is simply three channels of eight bits each of color accuracy[3].

Q: My Monitor is only Eight Bits Per Channel? Why Do I Care?

The monitor is an end point. It is an output device.

As soon as we begin to discuss the area of manipulation of images, we engage the issue of bit depth. In particular, we are speaking of bit depth accuracy. While the pipeline looks consistent at eight bits per channel from a starting eight bit JPG image to an eight bit per channel display device, we must also remember that the result of any and all manipulations are also constrained to the eight bit scale.

This results in intermediate values being rounded to fit within that scale. Many of these will end up being visible on an eight bit per channel monitor.

Q: These are microscopic theoretical differences aren't they? Why do I care?

You might not.

There is a good chance though, if you are an audience using an image manipulation program, you have at least a passing interest in output image quality. And if you do indeed care, bit depth calculation accuracy comes into the mix and brings with it visible output implications.

Remember that consecutive image manipulations are commonplace in an imaging editing system. Within a limited bit depth scale, those consecutive operations compound and conspire against each other and compound. Repeated rounding accuracy is cumulative in many instances.

The result is an output image that can be seriously degraded.

Q: There are some people that say this is all a myth and some that say it isn't, though. Is this real?

At risk of being inflammatory, anyone that suggests that the issue of bit depth only applies to deep outputs formats such as printing or deep professional grade sources, is unequivocally wrong.

For this however, we should turn to some demonstrations.

The first case study would be from the MyPaint application. MyPaint is a digital painting application. A good deal of design focus goes into focusing on digital painting and display output. The curator of MyPaint is Martin Reynolds and his exemplary mind has taken these sorts of mythical concepts to task in code.

Note that this is a scenario where many would suggest bit depth does not matter as we are trapped within the eight bit digital output of a typical display.

It should be clear from this image alone that in fact, there is a striking visible difference between eight bits and fifteen bits per channel representations. Even though the output source is identical in both scenarios, the internal math gives entirely different results.

From Martin Reynolds's example here deeper bit depth during computation has a visible and distinct impact on image quality.

The full article can be found at the MyPaint site. Full credit goes to Boudewijn Rempt at LWN for this citation and discussion. Boudewijn Rempt is a remarkable mind also contributing to the Krita project, so his opinions and expertise are backed up with a good deal of practical reference.

Q: Are there examples of differing bit depth sources that highlight the issue?

Yes.

A higher bit per channel input image holds more steps of data than a reduced eight bit channel image. This yields more granularity within the information.

A single image manipulation is provided in the following example. Notice how there is quite radical posterization, or color banding, in the image after only a single manipulation.

This sample is a crop from an existing article. The full article (author unknown) can be found PhotoshopEssentials. Full credit goes to julian37 at Hacker News for discussing and providing this example.

Q: So, limited eight bit working space influences all image manipulations even if the output is only destined for eight bit or less displays?

Yes.

In summary, strictly eight bit images operated on in an eight bit workspace will yield rounding errors that result in degraded image quality.

A simple way of expressing this is to consider a value of 127 red. It is fundamentally impossible to divide such a value in half without throwing out a degree of information. When we throw out that data, we are degrading the image in visibly noticeable ways. Greater bit depth work spaces provide significantly more accuracy and hence reduces the visual impact of this issue.

The limited range of 256 total steps per channel is obviously important. How important? What is the threshold for error?

"The magnitude of these errors is surprising. The brightest spots in the difference image correspond to a difference of only 2 pixel values!" -- Andrew Mihal experimenting with code on Enblend.

Martin Reynold's MyPaint example above beautifully illustrates this.

The issue becomes even more noticeable when we compare it against an image of deeper bit depth as in the second example.

Whether you are doing photographic or pure shape based imaging, the moment that we enter into a limited bit depth space such as eight bits per channel, we are discarding data accuracy when manipulating. Blurs, colour manipulations, compositing, and even simple anti-aliasing is impacted.

There is no magic here. There is no hypothesis or hyperbole. In the end, this is simple and fundamental math and rounding.

There is no question that this is a critically misunderstood issue surrounded in confusion and misinformation.

Whether this difference is noticeable and meaningful to the reader is a personal and subjective thought that shall remain open. For those more heavily involved with image manipulations and output thereof, this is a well documented and core issue.

Thank you all for reading...

Further reading:

The LWN thread regarding the implications of eight bit rounding.
The Hacker News thread regarding bit depth.
Andrew Mihal talks about precision and rounding errors.


If there are any inaccuracies or articles of further relevance, please comment and all efforts will be made to integrate them where appropriate.

[1] That includes anything to do with GEGL and what it brings to GIMP etc.
[2] This avoids the complications of color space transformations and like areas. It would likely only serve to confuse the issue without bringing much additional value to the discussion.
[3] It should also be noted that despite a huge number of graphics cards offering 32 bit in their titles, they offer only eight bits per RGB channel with an additional eight bit transparency layer. It is current convention that true ten bit per channel video cards are presented as 30 bit cards to avoid this confusing piece of historical legacy.

Why GIMP is Inadequate

Update

I'll let the image speak for itself. While other issues remain, this is a massive and significant addition to the software. Let's watch how things unfold.

Famous or Infamous?

GIMP is perhaps one of the most well known imaging apps available in Libre software. Its virtues are endorsed by many in the Libre software community. In a practical sense however, within North American art and design circles, its uptake is effectively zero.

There are reasons behind this, although any attempts to tackle the issues have a tendency to erupt into nothing more than hyperbole and animosity, leaving behind the core issues at hand.

This is an attempt to outline three key reasons why some graphic artists and designers perceive GIMP as inadequate when it comes to its suitability in their imaging pipelines[1].

Precision
Update: There appears to be quite a bit of confusion regarding bit depth both for ingestion and for calculations. To this end, a follow up article was crafted to specifically explore some of the issues regarding bit depth.

Public bug reported in 2002 and covers deeper than 16bpc.

Pixels are stored in discrete units of bits. GIMP has a hard limit of eight bits per channel at its highest depth. This means that all colour is locked into 0 to 255 steps.

Why is this an issue?

Ultimately this is a question of quality. There is no arguing that insufficient bit depth will always lead to a degradation of image quality. Posterization is the most obvious impact of restricted bit depths.

Every action in GIMP throws data out. Import an inexpensive camera's output in RAW format and you throw out data, irreversibly forcing the 12-14 bit per channel data into 8 bit per channel internal resolution. Color selections, blurs, and every data related manipulation will be fundamentally restricted.

Pundits that suggest this is negotiable are simply and flagrantly incorrect[2]. Quality is quality. Good enough is not good enough given these constraints.

Performance

Related to this bug report from 2005, but likely covers a little more as it applies to purely round brushes as well.

Print work operates at a high DPI count. If we assume 300DPI as a baseline for work, we can quickly see how the numbers grow as our dimensions increase. A standard letter sized print at 8.5"x11" would yield dimensions of 2550x3300[3].

At those dimensions, large brushes are required. Setting a brush to a radius of 50 and working at a 1:1 resolution yields performance that is well beyond sub-optimal.

All manipulations on this size suffer. Multi-core processing may help, but ultimately this is the domain of less-than-glamorous profiling and optimizing. Graphics processor acceleration is device dependent and can yield inconsistencies across platforms or graphics cards[4].

Linear Light

As a result of cathode ray tubes and other legacy alchemy, the images you view on your computer monitor come preset and "baked" with various imaging variables. One of which is known as gamma.

When doing manipulations on images within this preset world, the math falls apart. You cannot simply add one unit of red to one unit of red and get to two units of red.

Linear light solves this by reversing the gamma present in images and formatting all of the pixels into a linear space. Certain image manipulations involving light based concepts such as light leaks are much more efficient to achieve using a linear light model.

In addition to this, a linear light option allows imaging pipelines to integrate with the system, as many higher end pipelines rely on linear light models.

The Long Road

GIMP is a valuable tool to hobby imaging. In its current incarnation, GIMP has many shortcomings that inhibit its usage by many talented artists. There are certainly an extremely rare and dedicated few that have created spectacular work using the GIMP, and those people are indispensable to increasing GIMP's credibility and acceptance. Unfortunately, personal and ethical software choices cannot alone create and evolve artist tools within a project.

With its inherent low ability ceilings, lack of industry support, and fundamental core issues, aspiring graphics arts individuals often simply skip over GIMP and move onto alternate options.

What is Wrong?

If we read and accept the current state of GIMP's development to be dire with only two principal developers left, we can see that the project might have a rough road ahead.

How is it that the flagship imaging application struggles along with only two principal developers working on it and an alternate project such as Blender is absolutely thriving in Libre software? To an outsider, this might be interpreted as a symptom of a lower level dysfunction.

Back to Audience

Are there any solutions out there for the GIMP dilemma?

It would seem logical that with GIMP's currently suffocating level of principal developers that an investment in priorities would be well spent.

Is GIMP seeking to be an advanced or professional grade imaging tool or is it a hobby grade application?

In a private discussion, Michael Terry of the University of Waterloo offered that the largest percentage of GIMP's user base was amateur and hobby individuals. Should GIMP perhaps alter its course to focus and elevate its usefulness to this audience? Even acknowledging an amateur imaging audience doesn't eradicate the above issues either, as it is more likely that an amateur photographer will require exposure correction that uses the deeper bit depth than a seasoned veteran.

If GIMP has aspirations to be a professional grade tool, then it indeed needs to prioritize the needs of the artists and technicians in those environments above all else. Is single window mode a priority over deep bit depths when the vast bulk of professional artists are working in a multi window Photoshop on an Apple Macintosh product environment?

The Future?

It is a sincere hope that GIMP finds itself in the near future. Current and, more importantly, future Libre artists rely on it extensively.

All that we can do is ask questions. Is there something wrong with the GIMP development model that prevents growth? Is there anything that could be done to help GIMP achieve the dedicated and passionate developer core that Blender currently has? What can we do as a community to ensure that Libre raster imaging software is a growth area?

GIMP's situation is troubling.

GIMP has factual and easily verifiable shortcomings as an imaging app. Arguing that fact is simply in the realm of delusion. This post has attempted to outline three potential show stoppers for digital artists.

Does GIMP have an identity crisis between the desire to be an advanced imaging editor and the practical reality of its ability? What would sharp and deliberate decisions about audience do to the project[5]?

Does GIMP have an eroding development model? Is there a similarity between GIMP and the erosion that happened at Open Office?

Is there anything that can be done to rectify this situation[6]?

Thank you all for reading...

[1] Interface elements have been left out. Indeed, some of the recent pursuits over single window mode seem glaringly strange given the lack of software ability. It also leaves out some obvious complicating deficiencies in the performance section regarding CMYK subtractive colour modelling for print.
[2] You cannot sandwich images together. Anyone that suggests this as a workaround is about as far away from a credible opinion as you could ask. Also, it still fails to address manipulations within the application such as masking, blurring, scaling, rotating, and other such tools beyond the scope of a RAW image editor.
[3] This obviously is a very basic value as you would most certainly have to include bleeds and like details in a pre-press image.
[4] This doesn't even begin to discuss the complexities of closed and open graphics card driver dilemmas.
[5] Krita recently has made this difficult decision and has been making what appears to be solid progress with a fresh and refined perspective.
[6] Please resist suggesting funding as this appears to be a community based issue. There are countless examples of funding that yields nothing, let alone the practical cost / benefit example of simply purchasing proprietary software. It is, in this context, a completely tangential discussion.