GNOME Bugzilla – Bug 785535
Histogram not updating in real time when filters are active
Last modified: 2017-08-11 01:21:01 UTC
Histogram waits until I finish an adjustment, like levels or brightness, before updating.
I have fixed this locally but the fix requires an addition to GEGL which needs to be discussed. Stay tuned :)
Ok thanks for the update
Ok here is what's needed: we need to be able to create a histogram from both the layer's original buffer, and from the output of the filter graph on top of the layer. GimpHistogram currently uses a GeglBufferIterator, so I hacked up GeglBufferIterator to be able to read from a GeglNode, a better API would be: GeglIterator gegl_iterator_new_empty() gegl_iterator_new_buffer() gegl_iterator_new_node() gegl_iterator_add_buffer() gegl_iterator_add_node() the rest just renamed gegl_buffer_iterator -> gegl_iterator But for now I'll attach a patch that simply adds gegl_buffer_iterator_add_node()
Created attachment 356676 [details] [review] Implements gegl_buffer_iterator_add_node()
GeglBuffer as the data storage foundation should not itself be using any graph APIs, a possibility that has been kept possible and should continue being kept possible is splitting GeglBuffer out to a separate library that GEGL can depend on. Adding a single node to process the buffer also breaks expectations of how nodes are used in gegl, what if one wanted to have a chain of nodes? It seems more reasonable to add better iteration API for nodes that can be used in along with/instead of gegl_node_blit.
"Node to process the buffer"? I don't understand. The nodes added via that new iterator api are the outputs of complete graphs of course. And the killer feature is actually to be able to iterate over buffers *and* graph outputs at the same time.
Ah, I haven't had time to more than a couple of glances on the patch. Maybe what needs to be done is to have both a gegl_buffer_iterator_ API in GeglBuffer and a gegl_iterator_ API in GEGL, that either duplicates or reuses infrastructure provided by GeglBuffer.
I would be willing to create a GeglIterator in graph/ or perhaps better process/, for now duplicating the code. I'm not quite sure about a good apptoach to re-use the GeglBufferIterator code tho.
Comment on attachment 356676 [details] [review] Implements gegl_buffer_iterator_add_node() This patch is now attached to a GEGL bug.
Fixed in master: commit c41e8eca86df42bb92905b7be9670334d377709f Author: Michael Natterer <mitch@gimp.org> Date: Sat Aug 5 17:15:31 2017 +0200 Bug 785535 - Histogram not updating in real when filters are active Add "gboolean with_filters" to gimp_drawable_calculate_histogram(), which is passed as FALSE in almost all places, except the histogram dockable where we want to see both the drawable's unmodified histogram *and* the histogram after filters are applied. app/core/gimpdrawable-equalize.c | 10 ++++---- app/core/gimpdrawable-histogram.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++--------- app/core/gimpdrawable-histogram.h | 3 ++- app/core/gimpdrawable-levels.c | 2 +- app/pdb/color-cmds.c | 2 +- app/pdb/drawable-color-cmds.c | 2 +- app/tools/gimpcurvestool.c | 2 +- app/tools/gimplevelstool.c | 2 +- app/tools/gimpthresholdtool.c | 2 +- app/widgets/gimphistogrameditor.c | 10 +++----- tools/pdbgen/pdb/color.pdb | 2 +- tools/pdbgen/pdb/drawable_color.pdb | 2 +- 12 files changed, 77 insertions(+), 32 deletions(-)
That awesome it is fixed! It is kind of strange though nobody mentioned it before . . . or maybe they did and just didn't say anything or I just was in the dark about all of it. Anyway, thanks for fixing it. With more than 8 bits Gimp is much more useful when adjusting the levels and curves without those massive gaps in the histogram that 8 bits leave around.