GNOME Bugzilla – Bug 735895
Precision Conversion "Dithering" dialog
Last modified: 2016-11-10 11:16:32 UTC
When using the Precision Conversion dialog to change precision, the option to Dither almost always pops up. There should be a user option to say "No dithering" one time rather than having to say "No dithering" every time the image precision is changed. To cover all the bases, the same user option dialog could also allow to specify "yes, use these specific dithering options", plus "ask every time".
The same is true for a lot of dialogs. Do we really want to have such an amount of options for all of them? I vote for WONTFIX, any other opinions?
Some comments about GIMP's dither dialog: It pops up whenever a user converts from: * 64-bit to 32-bit precision * 32-bit gamma to 32-bit linear * any 32-bit precision to any 16-bit or 8-bit precision * any 16-bit precision to any 8-bit precision * 32-bit floating point to 32-bit integer, even though 32i has greater precision than 32f * 16f to 16i, even though 16i has greater precision than 32f It DOESN'T pop up when the user goes from 8-bit precision to a higher precision. In my opinion, this is *precisely* a point where some kind of dither, or rather added RGB or LCH noise, is often very desirable. In PhotoShop there is a "dither" option that works very differently than GIMP's. I'm not saying that GIMP should emulate PhotoShop. I am saying that I understand from experience what the PhotoShop dither option does, and it works very well to solve some practical problems when dealing with 8-bit images. Here's a synopsis of the PhotoShop dither, based on my recollection of using CS2 and on these two articles: http://www.peachpit.com/articles/article.aspx?p=1315593&seqNum=4. http://help.adobe.com/en_US/creativesuite/cs/using/WS6A727430-9717-42df-B578-C0AC705C54F0.html The peachpit article says "When Use Dither is turned on, Photoshop adds a small amount of noise when the 8-bit channels are converted into the high-bit space, making banding or posterization much less likely to occur". The adobe article says that dither is used when converting an 8-bit image from one color space to another "to simulate a missing color that existed in the source space" that isn't present in the destination color space. Both articles note that the dither option adds file size to 8-bit images, which might not be wanted. The peachpit articles notes that adding dither might interfere with the requirements for scientific image editing. The PhotoShop ("PS") dither is an OPTION that can be globally applied or not applied based on the color management settings. There is no "per image" option. From my recollection, in PS the net effect of using the dither option was that when converting an 8-bit image to a higher precision, instead of having gaps, the converted image had a very nicely smoothed histogram, but without any visible loss of detail or added noise. Regardless of what PS did/does, when using GIMP, when editing an originally 8-bit sRGB camera-saved jpeg, my first step is to promote the precision to 32-bit floating point, and my second step is to add a very small amount of RGB noise (around 0.005 in all three channels, using perceptually uniform RGB, which is usually the preferred way to add RGB noise to an image). This added noise serves to fill in the gaps in the histogram. As currently set up, the GIMP dither dialog is intrusive. And I'm not sure what problem it's designed to solve. It doesn't solve the problem of gaps left in the histogram when converting an 8-bit image to a higher precision. There ought to be a way to permanently dismiss the dither dialog. This is a useability issue. In place of the dither dialog (or in addition to, if there actually is a use case for the GIMP dither dialog as currently programmed), GIMP users would benefit from having a user-configurable "always (or never) add this amount of RGB or LCH noise when promoting 8-bit images to a higher precision" and/or "when converting between ICC profiles for outputting an 8-bit image". I'm not sure how useful this latter option might be, but people who routinely print 8-bit images might have an answer. I can't think of any use cases for applying noise or dither when converting images between bit depths/precisions that are 16-bit integer or higher (ie 32f to 16i or vice versa). Could someone please explain the intended use cases for the current GIMP dither options?
We show the dither dialog when converting to a lower bit-per-pixel, and use gegl:color-reduction which does the dithering. This is a quick hack because it doesn't cover the cases you mention above. I knew we needed such a dialog so I set up the infrastructure for the dialog, and a way to pass its settings down to the actual function doing the conversion. The "to fewer bits" is also not entirely true, it simply checks if the new precision enum value is smaller than the old one :) The order is as in the Image -> Precision menu. I'm open to whatever suggestions, preferrably a complete proposal what options to reasonably offer the user when converting from a to b. Maybe even a hint text for the specific use case, because dithering to fewer bits is a different operation than adding noise when going to more bits. Also, can we keep this bug about the options and methods to offer in the dialog. Skipping the dialog due to preferences values, or a "Don't ask me again" toggle is actually another question. First the functionality, then the fancy stuff...
(In reply to Michael Natterer from comment #3) > I'm open to whatever suggestions, preferrably a complete proposal > what options to reasonably offer the user when converting from a to b. > Maybe even a hint text for the specific use case, because dithering > to fewer bits is a different operation than adding noise when going > to more bits. > Let's assume that "dither algorithms" such as Random, Resilient, etc, and also adding noise whether RGB or LCH, all qualify as "dither". Here are some thoughts towards a proposal, with "hint text" taken from the specific use cases: 1. When going from a higher bit depth to a lower bit depth, one use case for dithering is to avoid the appearance of banding in the output image, whether to the screen while editing, for display on the web, or for sending to a printer for printing. This use case really only applies to outputting an 8-bit image, on the assumption that higher bit depths have more tonal steps than the eye can discern. 2. A second use case for dithering/adding noise is when editing an image causes posterization from stretching too few tones across too large an image expanse during the course of editing. This can happen at higher bit depths, though it might sometimes only be from the appearance of banding caused by sending the image to the screen at a lower bit depth (which wouldn't be apparent on a high end/high bit depth monitor), which would reduce to the first use case. This appearance of banding can be solved by adding RGB or LCH noise or maybe by one of the dithering algorithms. I don't see any way the user can distinguish between this use case and the first use case. But in practice a dither dialog in the Filter menu would be nice to have just for such cases 3. I don't know of any use case for dither/adding noise that requires doing so when converting between bit depths/precisions that are higher than 16f/i. I do know a person I can ask, who makes a living pushing high bit depth pixels around. Maybe someone on the mailing lists knows of such a use case. 4. This web site (http://www.udel.edu/cookbook/scan-print/workspace/workspace.html) specifically mentions dithering in connection with converting images from one color space to another color space at 8-bits, and says to dither for printing, but not for exporting to the web. There are people on the mailing lists and IRC who print from 8-bit images, who can provide input on this use case. In the meantime, here are some suggestions for consideration: * Don't show the dither dialog when converting between bit depths that are equal to or higher than 16f/i. * Show the dither dialog when converting to 8-bit precision from any higher bit depth, and specifically when converting to another color space for output as an 8-bit image for printing. People who make prints from 8-bit files would know how to best handle dither for printing. * Add the option to dither/add noise when promoting an 8-bit image to any higher bit depth. * Add dithering as a Filter, with various options such as add RGB noise, add LCH noise, and whatever actual dither algorithms seem appropriate. > Also, can we keep this bug about the options and methods to offer in the > dialog. Skipping the dialog due to preferences values, or a "Don't ask > me again" toggle is actually another question. First the functionality, > then the fancy stuff... Ok, I'll open another bug on moving the dialog to Preferences.
(In reply to Elle Stone from comment #4) > * Add the option to dither/add noise when promoting an 8-bit image to any > higher bit depth. Well, that should have been listed as a use case, where the use case is creating smoother RGB data from quantized 8-bit data, to work with when editing at higher bit depths.
Sorry for the delay in getting back to this question. I did consult the person who makes his living in the VFX industry about use cases for dither. His advice was to use dither "only for 8-bpc output/display material. When working in scene-referred floating point domain NEVER use dithering, it's unnecessary." He also mentioned adding film grain for final display output to emulate various output devices. So yes, dithering, adding RGB or LCH noise, adding film grain, etc, can be useful for 8-bit output, but not for converting between higher bit depth precisions. In my own experience, adding RGB or LCH noise can be useful after importing 8-bit images and promoting them to higher bit depths, with "useful" being defined as "producing a smoother histogram". But I've promoted 8-bit images to higher bit depths without adding noise, followed by extensive processing, and not really noticed any disadvantages. So I'm not sure whether "useful" extends too far beyond producing a nicer looking histogram. So to summarize: * Dithering/adding RGB or LCH noise/adding film grain/etc is (1)Probably useful when changing from 8-bit to higher bit depths. (2)Useful and sometimes essential for outputting 8-bit images for display. * Dithering whould be avoided when converting between various higher bit depth precisions. * For the current pop-up dialog, I'd suggest disabling the dither dialog for every precision change except changes between higher bit depths and 8-bit precision. * An option to set precision conversion dither options globally - including disabling it altogether - should be added to Preferences (for which I'll file a bug report), for people who choose to take care of adding noise/dither/film grain/etc in some fashion other than by using the dither dialog.
This makes the dither settings persistent across sessions, step one... commit 98232c25a5eff91b7348749e753038af07eee8dd Author: Michael Natterer <mitch@gimp.org> Date: Mon Sep 26 17:38:26 2016 +0200 Bug 735895 - Precision Conversion "Dithering" dialog Remember the convert precision dialog's dithering options in GimpDialogConfig. Also addresses bug 599573. app/config/gimpdialogconfig.c | 57 ++++++++++++++++++++++ app/config/gimpdialogconfig.h | 4 ++ app/config/gimppluginconfig.c | 1 + app/config/gimprc-blurbs.h | 9 ++++ app/config/gimprc-serialize.c | 1 + app/config/gimprc.c | 1 + app/dialogs/convert-precision-dialog.c | 87 ++++++++++++++++++---------------- app/dialogs/preferences-dialog.c | 21 ++++++++ 8 files changed, 141 insertions(+), 40 deletions(-)
This is not a dialog change, but related anyway because it disables dithering where it make no logical sense at all (regardless of GUI policy). commit 56ce447bc90dc2928e1a9d9a5fbd7d0bb2ffa74b Author: Michael Natterer <mitch@gimp.org> Date: Wed Nov 9 12:45:52 2016 +0100 Bug 735895 - Precision Conversion "Dithering" dialog gimp_drawable_convert_type(): never dither when converting to a higher bit depth, or to anything more than 16 bits. app/core/gimpdrawable.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
This syncs the dialog with the internal logic: commit 91df48ef3708227ba2f2474b054baf62e2c7699a Author: Michael Natterer <mitch@gimp.org> Date: Wed Nov 9 13:10:56 2016 +0100 Bug 735895 - Precision Conversion "Dithering" dialog Disable the convert precision dialog's dithering controls when converting to higher bit depths o to anything > 16 bit. Make sure the disabled dithering widgets always says "None", which implies duplicating the bit depth checking logic in both the dialog and its callback, in order to protect the values in GimpDialogConfig from being overwritten by NONE. app/actions/image-commands.c | 31 ++++++++++++++++++++++ app/dialogs/convert-precision-dialog.c | 72 ++++++++++++++++++++++++++++++++------------------- 2 files changed, 77 insertions(+), 26 deletions(-)
AFAICS this seems done except two things: - decide if we want dithering only for converting down to 8 bit, or also for converting down to 16 bit, everything else is now disabled because it's impossible with gegl:color-reduction) - adding noise when converting to higher deptns is an entirely new thing I'm not sure about, maybe move that to later?
(In reply to Michael Natterer from comment #10) > AFAICS this seems done except two things: > > - decide if we want dithering only for converting down to 8 bit, or also > for converting down to 16 bit, everything else is now disabled because > it's impossible with gegl:color-reduction) Dithering (and/or adding RGB/LCH noise) is mostly useful for outputting final images for display or printing, to prevent posterization. I can't think of any use case for dithering when converting from a higher bit depth to 16-bit precision. I checked the resulting histograms from converting an 8-bit integer jpeg photographic image to 32-bit floating point linear precision and back down to 8-bit linear precision vs back down to 16-bit linear precision (linear precision being the precision that would produce the most change in the resulting histogram). There is a great big huge difference in the histograms before and after converting from 32 bits to 8 bit linear precision and back to 32 bits to make the "before/after" histogram comparison. There is an essentially indetectable difference in converting from 32 bits to 16 bit linear precision and back to 32 bits to make the "before/after" histogram comparison. > > - adding noise when converting to higher deptns is an entirely new thing > I'm not sure about, maybe move that to later? Even though dithering (or adding a small amount of RGB or LCH noise) when converting from 8-bits to a higher bit depth does produce a smoother histogram, in practice the visual differences (from actual image editing with and without such initial dithering/added noise) seem to be "nil". The user already has the option to add RGB or LCH noise if seeing a smoother histogram is a priority and/or does affect the final image for any given editing procedure or starting image. The option to dither or add noise when converting from 8-bit precision to a higher precision seems to me to be a very low priority enhancement request. I would suggest leaving adding noise or dithering when converting from 8-bits to a higher precision entirely up to the user to do, at least unless and until a user makes a new bug report requesting that GIMP offer such an option.
Thanks a lot for this good analysis, will restrict to 8-bit dithering and close the bug :)
Fixed in master: commit 0631f1c6293bd3131d8e969178c2bea74387934c Author: Michael Natterer <mitch@gimp.org> Date: Thu Nov 10 12:11:19 2016 +0100 Bug 735895 - Precision Conversion "Dithering" dialog Don't offer dithering options when converting to 16 bit, it doesn't make much sense to dither for anything but 8 bit. Thanks to Elle for testing that this assumption is indeed true. Use a properly commented #define instead of just a hardcoded "8 bits" to make clear that this is a pure GUI "restriction". app/actions/image-commands.c | 6 +++--- app/dialogs/convert-precision-dialog.c | 7 ++++--- app/dialogs/convert-precision-dialog.h | 8 ++++++++ 3 files changed, 15 insertions(+), 6 deletions(-)