RSS/Atom feed Twitter
Site is read-only, email is disabled

some gimply thoughts

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

6 of 6 messages available
Toggle history

Please log in to manage your subscriptions.

some gimply thoughts Liam R E Quin 21 Nov 07:30
  some gimply thoughts David Gowers 21 Nov 11:24
some gimply thoughts Liam R E Quin 22 Nov 00:15
  some gimply thoughts David Gowers 22 Nov 06:14
   some gimply thoughts GSR - FR 22 Nov 20:33
    some gimply thoughts David Gowers 22 Nov 23:46
Liam R E Quin
2007-11-21 07:30:50 UTC (about 17 years ago)

some gimply thoughts

I saved these notes for when there was a 2.6, but then got swamped with other things... I can flesh them out more, but I'm not likely to have time to do any programming in the forseeable future, I'm afraid.

selction optimization on subtracting (e.g. control is pressed), compute the bounding box of the current selection (including the feather radius) and don't try & go outside it with the new one; you see this if you're using select-by-colour or the magic wand, say, and you have to wait ages for it to calculate the selection over a 500MByte image... images are getting bigger faster than computers are getting faster right now.

Preferences Create open file previews even if layer previews are off Allow the user to reset a single pref. category, nut just everything

File->open show more detailed times and dates on files

in tip of the day, "learn more" links to documentation and to tutorials in the manual

in the undo window (I hope to do some pictures of this) "creative explorer"?
click on image state, transitions shown between Right now to undo something you have to click on the previous operation -- e.g:
create a new image, paint, then erase, Undo History looks like [thumb1] Base Image
[thumb2] PaintBrush
[thumb3] Eraser levels
"auto" loses detail by default; change so it doesn't, but maybe have a "highlight and depth crop amount" of 3%
Sorry these are awfully terse. Sending them rather than not send them... can file individual bugzillae or messages if it makes sense.

Liam

David Gowers
2007-11-21 11:24:06 UTC (about 17 years ago)

some gimply thoughts

Hi Liam,

On Nov 21, 2007 5:00 PM, Liam R E Quin wrote:

I saved these notes for when there was a 2.6, but then got swamped with other things... I can flesh them out more, but I'm not likely to have time to do any programming in the forseeable future, I'm afraid.

I've scattered comments throughout, hopefully this helps..

selction optimization
on subtracting (e.g. control is pressed), compute the bounding box of the current selection (including the feather radius) and don't try & go outside it with the new one; you see this if you're using select-by-colour or the magic wand, say, and you have to wait ages for it to calculate the selection over a 500MByte image... images are getting bigger faster than computers are getting faster right now.

Might be unneeded complexity. For a selection outline preview, it would be simpler to apply the magic wand to a shrunk version of the image while it is in operation, and only apply the magic wand to the complete image when the user releases the button.

Preferences
Create open file previews even if layer previews are off Allow the user to reset a single pref. category, nut just everything

File->open show more detailed times and dates on files

in tip of the day, "learn more" links to documentation and to tutorials in the manual

in the undo window (I hope to do some pictures of this) "creative explorer"?
click on image state, transitions shown between Right now to undo something you have to click on the previous operation -- e.g:
create a new image, paint, then erase, Undo History looks like [thumb1] Base Image
[thumb2] PaintBrush
[thumb3] Eraser

quickmask to work wih red mask even in grayscale images

This would require channels to be drawn after the gray->RGB internal conversion but before the display filters come into effect.

drawing
when you use shift to make a straight line, draw two lines, showing the outline of the brush (tangents), not just one line.

This might be tricky, but doable. I would find it very useful. To be reasonable,
this probably would need to just draw an extruded diamond (the points of the diamond
being the midpoints of each side of the brush image.

when you change hardness/size, e.g. with a keystroke or by pressing harder, show the actual brush in place for a moment

Cairo might help here.

filter brushes - paint with a filter (Krita has this by the way)

beyond 2.6, but definitely something desirable in the long term -- one of peter's posts at his UI blog outlines a 'blobs of paint' idea that includes this.

text
justify-both doesn't seem to work, probably because there's no obvious way to control line length.

kerning

access to opentype features (e.g. small caps)

access to arbitrary glyphs

hung punctuation

etc etc :-)

plugins and filters

colourise show the Hue by the Hue slider, or use a colour picker

merge visible layers if all layers are the same size, and the same size as the image, don't ask whether to clip them.

nice simple enhancement.

condense/stretch font

retain textness on image scaling and layer scaling

automatic white balance - allow the user to pick black and white points

.. It would then not be automatic white balance, but manual or partially-automatic white balance.

menus
rename Image->crop image to Image->Crop to Selection same with layer->crop

dodge want to be able to specify what's meant by midtones, highlight, etc. really, want a "curves brush".

Is this really related to dodge/burn tool? Isn't a curves brush a case of 'filter brush'?

tips
the doge tool is usually most effective if you make lots of short, separate strokes.

convolve select radius...

colours->levels "auto" loses detail by default; change so it doesn't, but maybe have a "highlight and depth crop amount" of 3%

Could you present evidence of this? From what I understand of the 'auto levels' function, it can never reduce the range of the output, only expand it, so any lack of detail is due to hidden lack of detail in the input image.

Sorry these are awfully terse. Sending them rather than not send them... can file individual bugzillae or messages if it makes sense.

Liam

-- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org

Liam R E Quin
2007-11-22 00:15:27 UTC (about 17 years ago)

some gimply thoughts

Evidence that auto levels loses details -- take a photograph (or a scanned engraving, or whatever) and open Levels, and press autl. Note that the little triangles marking the end-points are not under the ends of the black part - in other words there are multiple pixel values that are used in the image that end up having the same value after "levels". I'll attach a screenshot that shows the triangle isn't at the end of all the values, but some way in. This behaviour is good in some cases and not others.

Liam

David Gowers
2007-11-22 06:14:46 UTC (about 17 years ago)

some gimply thoughts

Hi Liam,

On Nov 22, 2007 9:45 AM, Liam R E Quin wrote:

Evidence that auto levels loses details -- take a photograph (or a scanned engraving, or whatever) and open Levels, and press autl. Note that the little triangles marking the end-points are not under the ends of the black part - in

The 'Value' controls are not effected by 'Auto'. Look at the R,G,B,(A) controls instead.

All 'Auto' does, is: 1. Set the input range to min(CHANNEL), max(CHANNEL) -- ie the lowest used value of that channel in the picture, and the highest used value of that channel in the picture. 2. Set the output range to 0, 255 for each CHANNEL in R,G,B (and possibly A)

Because the output range is full, there is literally no way that this operation can reduce detail.

other words there are multiple pixel values that are used in the image that end up having the same value after "levels". I'll

'Value' is invalid after applying Auto, cause you either use Value or R,G,B, not both. If you change the Value controls, then adjusting RGB individually is meaningless, and vice versa. GIMP makes some effort at showing sensible values for all controls though -- the range you show is probably the average of the R,G,B ranges.

attach a screenshot that shows the triangle isn't at the end of all the values, but some way in. This behaviour is good in some cases and not others.

Liam

--

GSR - FR
2007-11-22 20:33:10 UTC (about 17 years ago)

some gimply thoughts

Hi,
00ai99@gmail.com (2007-11-22 at 1544.46 +1030):

Hi Liam,

On Nov 22, 2007 9:45 AM, Liam R E Quin wrote:

Evidence that auto levels loses details -- take a photograph (or a scanned engraving, or whatever) and open Levels, and press autl. Note that the little triangles marking the end-points are not under the ends of the black part - in

The 'Value' controls are not effected by 'Auto'. Look at the R,G,B,(A) controls instead.

And then you see it changes them, in a destructive way.

All 'Auto' does, is:
1. Set the input range to min(CHANNEL), max(CHANNEL) -- ie the lowest used value of that channel in the picture, and the highest used value of that channel in the picture.

No, it does not. It sets min and max "inside" the histrogram used range (play with Lin/Log setting if this is not clear). There is a way anybody can test it:

1 Create new image, 512*512 2 Render plasma, with seed 0 and turbulence 1 3 Run Levels, click the auto button, look at all the channels.... OOPS!

You get: R 9 1.0 229 | 0 255
G 12 1.0 194 | 0 255
B 25 1.0 241 | 0 255

Those settings are destructive, Red 0-9 becomes 0, Red 229-255 becomes 255, and so on. You can look for such pixels before applying the operation, mark with guides or points, then look what they are after.

You can also look at the code and see how it iterates over the histrogram until it decides it has "eaten" enough. It does not stop when it reaches the first non zero, which would be non destructive (as in any input channel value gets mapped to a new, different, output value, rounding and precission issues aside).

2. Set the output range to 0, 255 for each CHANNEL in R,G,B (and possibly A)

Because the output range is full, there is literally no way that this operation can reduce detail.

If the input range is not full, there is loss, as shadows and highlights are lost and become flattened, grouped in the same result.

GSR

David Gowers
2007-11-22 23:46:34 UTC (about 17 years ago)

some gimply thoughts

On Nov 23, 2007 6:03 AM, GSR - FR wrote:

Hi,
00ai99@gmail.com (2007-11-22 at 1544.46 +1030):

Hi Liam,

On Nov 22, 2007 9:45 AM, Liam R E Quin wrote:

Evidence that auto levels loses details -- take a photograph (or a scanned engraving, or whatever) and open Levels, and press autl. Note that the little triangles marking the end-points are not under the ends of the black part - in

The 'Value' controls are not effected by 'Auto'. Look at the R,G,B,(A) controls instead.

And then you see it changes them, in a destructive way.

All 'Auto' does, is:
1. Set the input range to min(CHANNEL), max(CHANNEL) -- ie the lowest used value of that channel in the picture, and the highest used value of that channel in the picture.

No, it does not. It sets min and max "inside" the histrogram used range (play with Lin/Log setting if this is not clear). There is a way anybody can test it:

1 Create new image, 512*512 2 Render plasma, with seed 0 and turbulence 1 3 Run Levels, click the auto button, look at all the channels.... OOPS!

You get: R 9 1.0 229 | 0 255
G 12 1.0 194 | 0 255
B 25 1.0 241 | 0 255

Those settings are destructive, Red 0-9 becomes 0, Red 229-255 becomes 255, and so on. You can look for such pixels before applying the operation, mark with guides or points, then look what they are after.

You can also look at the code and see how it iterates over the histrogram until it decides it has "eaten" enough. It does not stop when it reaches the first non zero, which would be non destructive (as in any input channel value gets mapped to a new, different, output value, rounding and precission issues aside).

Okay, well this is not what I expected and I won't be using Levels Auto in the future - I hate clipping. I had thought that Auto was supposed to perform the same function as Colors->Auto->Stretch contrast -- to stretch the current R,G,B range ends to 0,255, clearly it doesn't.

It would be nice to have an Auto button in Curves that did achieve this result.

2. Set the output range to 0, 255 for each CHANNEL in R,G,B (and possibly A)

Because the output range is full, there is literally no way that this operation can reduce detail.

If the input range is not full, there is loss, as shadows and highlights are lost and become flattened, grouped in the same result.

GSR