GNOME Bugzilla – Bug 772126
Make GimpColorFrame handle very long numbers
Last modified: 2018-04-03 15:09:29 UTC
Created attachment 336449 [details]
Automatically resized toolbox
With the Pointer dialog in the toolbox, when hovering the tool cursor over RGB values that go from low values up to very large values, the toolbox constantly resizes itself.
The first time this happened the area in the image with the very large RGB values was small and irregular, and the Pointer dialog wasn't showing, so I wasn't sure what was causing the toolbox to seemingly randomly resize itself. But it turned out to be the Pointer dialog. Most likely the Sample Point dialog would cause similar resizing.
In Multi Window Mode the resizing depends on the RGB values over which the tool cursor is hovering, and the resizing stops at the current size then the tool cursor stops moving.
In Single Window Mode, the cursor can be placed such that the flickering/resizing never stops, at least on Gentoo.
As shown in the attached screenshot, usually I have the toolbox set up with two vertical panels. If the Pointer dialog is in the right-hand side panel, there is no resizing - the RGB values are simply squeezed over the top of other writing, making the values illegible. This might sound like undesireable behavior, but in fact the flickering from the toolbox automatically resizing itself is much worse than having to either deliberately change the size of the toolbox or else simply drag the Pointer dialog out as a separate window.
There is a related issue, which is that this automatic resizing seems to happen other times, making it impossible to make the left-side panel of the toolbox as narrow as I'd like it to be (the right-side panel can be resized freely) - once the left-side panel is automatically resized larger, there doesn't seem to be any easy way to put it back to the originally set width.
This is on Gentoo running GIMP commit e1db363, and confirmed on Debian testing, except on Debian testing I wasn't able to reproduce the flickering in Single Window Mode, probably because the test file that I made on Debian testing didn't have large enough RGB channel values. There seems to be a non-related bug? feature? in default GIMP that prevents using Levels or Exposure to create RGB values larger than about 18 stops above display-referred white (1.0, 1.0, 1.0) - after this point the RGB values actually go negative (I plan to file a separate bug report on this).
Created attachment 336451 [details]
EXR file with very large RGB values to the left, diminishing to 0 on the right
If the Pointer dialog is on the left-hand side of a two-column toolbox in Multi Window Mode, running the cursor back and forth from side to side of the exr file causes the left-hand side of the toolbox to continuously resize.
How evil, you are mean :)
Will look into it...
Created attachment 337200 [details]
Left pane of toolbox automatically resized by the palette
(In reply to Michael Natterer from comment #2)
> How evil, you are mean :)
> Will look into it...
My apologies for being so mean! I've known for a long time "something" was odd about the toolbox and certain dialogs, but wasn't able to pin it down. Anyway, I added a screenshot showing resizing from moving the palette from the right pane to the left pane of a two-pane toolbox. I've been trying to optimize the "toolbox vs screen real estate" for painting (which requires a lot more dockers than photographic editing), and the "auto resizing" behavior puts fairly stringent limitations on how the dockers can be arranged.
That's not a problem of the toolbox, it can't become smaller than
the widest dockable it contains.
This is a problem of GimpColorFrame, we can't allow it to grow
like that just because color values are huge.
I don't think we can ship a "high precision GIMP" with this
*** Bug 789993 has been marked as a duplicate of this bug. ***
So basically in your example file, the RGB component values are over 100%. That's perfectly valid? I know that it is theoretically valid (color out of the current color space), but I didn't know that it was valid to save colors outside the color space in any file format.
Floating point exrs and tiffs can save very, very large numbers, many stops above 100% (1.0f). This is useful for working with high dynamic range images, meaning images who's maximum value is considerably above middle (18%) gray.
Think of a scene-referred (pre-tone-mapping) image of a sunny day at the beach, with highlights sparkling off the water and direct sunshine on the wall of a white building, with deep shade cast by an adjoining wall. Throw in some sand and an umbrella casting open shade just on the shore, with people under the umbrella. Maybe you set middle gray on the open shade under the umbrella. This type of scene requires multiple ev-bracketed shots (saved as raw files, not as jpegs) to capture the entire scene without losing information in the shadows and highlights. The merged image is a high dynamic range scene-referred image. It won't fit into the range from 0% to 100% until it's been tone-mapped.
This should do the trick:
Author: Michael Natterer <email@example.com>
Date: Tue Apr 3 01:45:27 2018 +0200
Bug 772126 - Make GimpColorFrame handle very long numbers
Add "ellipsize" property to GimpColorFrame and set it to
PANGO_ELLIPSIZE_END in the the pointer information dockable.
Better cut off long numbers than make them expand the dock.
app/display/gimpcursorview.c | 2 ++
app/widgets/gimpcolorframe.c | 41 +++++++++++++++++++++++++++++++++++++++--
app/widgets/gimpcolorframe.h | 5 +++++
3 files changed, 46 insertions(+), 2 deletions(-)
It doesn't seem to fix the "related issue" described here (and also in my duplicate bug 789993) - docking the pointer dialog in the two column layout with toolbar makes its minimal width much bigger. I can attach screenshots illustrating the issue if necessary.
(In reply to Tomasz Goliński from comment #10)
> It doesn't seem to fix the "related issue" described here (and also in my
> duplicate bug 789993) - docking the pointer dialog in the two column layout
> with toolbar makes its minimal width much bigger. I can attach screenshots
> illustrating the issue if necessary.
Screenshots is a good idea to understand the issue, but also reproduction steps. I tried a 2-column layout, and didn't see any dock resizing. Some step-by-step procedure would be useful ((1) do this (2) do that…).
Created attachment 370486 [details]
right column does not resize when adding the pointer dialog under the tools area
At least on my Gentoo Linux setup, now moving the pointer tab to under the tool area in a two-column setup does no longer force the second column to resize. Maybe this is depending on which of the two columns holds the tool area?
The remaining issue that I have with the two-column set-up (with tools on the right) is that I can't resize just the left column. Instead I have to resize the right column (make it wider), and then resize the left column - make it wider, which also makes the right column narrower, but not as narrow as I want it to be. And then moving the right column back to its original narrower width also shrinks the left column back to its original narrower width.
In other words, there doesn't seem to be a way to adjust the width of the left column independently of the right column, though the right column width easily can be adjusted independently of the left column.
Created attachment 370487 [details]
Docking the pointer
I start Gimp with clean config.
1. Disable single-window mode.
2. Add a second column to the toolbox floating dialog, resize to make it reasonably tight.
3. Add pointer dialog to the mix, in the second column. The size stays tight.
4. Move pointer dialog to the first column, under the toolbox. Pointer dialog gets much bigger. It is impossible to make first column any narrower.
Moreover in the setup 3. moving the divider between columns enforces some limits on column widths (although not as radical as in 4.), but resizing the whole dock (either dragging left or right border) doesn't check for any constrains and allows to make it so small e.g. the second column entirely disappears.
(In reply to Tomasz Goliński from comment #13)
> Created attachment 370487 [details]
> Docking the pointer
> I start Gimp with clean config.
> 1. Disable single-window mode.
> 2. Add a second column to the toolbox floating dialog, resize to make it
> reasonably tight.
> 3. Add pointer dialog to the mix, in the second column. The size stays tight.
> 4. Move pointer dialog to the first column, under the toolbox. Pointer
> dialog gets much bigger. It is impossible to make first column any narrower.
> Moreover in the setup 3. moving the divider between columns enforces some
> limits on column widths (although not as radical as in 4.), but resizing the
> whole dock (either dragging left or right border) doesn't check for any
> constrains and allows to make it so small e.g. the second column entirely
Hmm, yes, putting the tools in the left column completely changes the behavior. I restarted GIMP with a clean config and changed to MWM. I added a second column in the toolbox and put channels, brushes, layers, and device status in this second right-side column, leaving the tools in the left column. Then I added the pointer dialog to the left column under the tools, at which point the left column expanded to the point where the right column actually vanished - I had to make the toolbox wider to make the right column reappear.
I changed the status of this bug report to reopened, fwiw.
That is indeed pretty hilarious, now can reproduce it.
Let's go back to bug 789993, this one was turned into the long
number thing and that's at least fixed now.