Re: [Gimp-developer] Fwd: GIMP Levels operation fix
Hi, On Tue, 2008-02-05 at 17:50 +1030, David Gowers wrote: > Basically it fixes over/underflow in the Levels op; Your approach is not the right way to fix this. There is absolutely nothing wrong with under- and overflows if we are using GEGL. The problem you are seeing is that some of the float->8bit conversions in babl are not handling colors outside the 0..1 range properly. You can fix this by running GIMP with the environment variable BABL_ERROR set to 0.0. This will select correct, but slower, conversion routines and you will notice that this fixes the error. We need to fix this in babl. Conversions that don't deal correctly with values outside the [0.0;1.0] inverval need to be assigned a large error so that they are not being selected. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Fwd: GIMP Levels operation fix
Hi, I sent this simple fix to mitch, however I'm too impatient to
wait for mitch to check his inbox,
So I'm now passing it onto this mailing list.
Basically it fixes over/underflow in the Levels op; with the attached
image, the bug gives the appearance of a triangle wave repeating
gradient, instead of a readjusted single gradient for the channel
being adjusted.
-- Forwarded message --
From: David Gowers <[EMAIL PROTECTED]>
Date: Jan 31, 2008 5:45 PM
Subject: GIMP Levels operation
To: Michael Natterer <[EMAIL PROTECTED]>
I've just found a bug in the Levels op -- if the selected low/hi input
endpoints of a channel are
(low -> more than the lowest non-empty histogram entry; or high ->less
than the highest non-empty histogram entry for the channel)
then underflow/overflow happens.
Adjusting any of the input range sliders to fall into that range will
show this behaviour up.
Using the channels dialog to disable all but one channel also helps. I
would say you have simply forgotten to clip the input values before
mapping them to output values. *pokes around* indeed, I've attached a
very short patch that performs correct clipping. With this patch, GEGL
levels op matches old levels behaviour in all tests I could contrive.
<>Index: app/gegl/gimpoperationlevels.c
===
--- app/gegl/gimpoperationlevels.c (revision 24754)
+++ app/gegl/gimpoperationlevels.c (working copy)
@@ -87,6 +87,8 @@
else
value = (value - low_input);
+ value = CLAMP (value, 0.0, 1.0 );
+
if (gamma != 0.0)
{
if (value >= 0.0)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement - Diagonal line crop guide
On Mon, 2007-11-12 at 21:29 +0100, Sven Neumann wrote:
> On Tue, 2007-11-06 at 23:03 -0500, Tim Jedlicka wrote:
>
> > I stumbled upon this link describing the use of the Diagonal (45
> > degree diagonal from each corner of an image) as the optimum crop
> > guide ("better" than rule-of-thirds or golden rule).
> >
> > http://www.diagonaalmethode.nl/
This has been a rule of composition since the Middle Ages.
Probably I can find you some references. Tschicholde's
page layout diagrams, and Leonardo's writing, may help.
But I am not sure that 45 degree lines from the corners of the crop
rectangle would be sensible.
It might be better to allow diagonal guides, and have the corners
of the crop box have a "snap to guides" behaviour, rather than
build into the crop tool every possible kind of proportion.
You'd position the diagonals according to the image features,
and then crop.
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
>
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gaussian blur: Silly question or buffer error?
On Feb 4, 2008 1:27 PM, Alastair M. Robinson <[EMAIL PROTECTED]> wrote: > Hi, > > I may be missing something obvious here, but I'm trying to understand > the workings of the Gaussian Blur plugin, since I need to implement > something similar myself, and either there's something screwy here, or > there's something obvious I'm missing. I'm not going to try to parse the code in an email message, but although it is quite difficult to read, it is set up to avoid referring to any unallocated memory (otherwise it would crash, or at least generate errors in valgrind). The crucial fact, which may help you understand the code, is that a 2D Gaussian blur can be implemented by doing two 1D Gaussian blurs, first vertically, then horizontally. Thus, the code starts out by doing a 1D blur on each column of the image. When this is finished, the result is processed by independently blurring each row. It is a remarkable theorem that this sequence of two 1D convolutions gives exactly the same result as the full 2D convolution -- at least, it gives the same result if the region is rectangular and all pixels are fully selected and equally weighted. Basically this happens because the kernel of the 2D Gaussian blur factors: exp (-(x^2 + y^2)) = exp (-x^2) * exp (-y^2). This allows the double integral in the 2D convolution to be factored into a product of two single integrals, over x and y. Unfortunately, I don't have a good reference to point you to, but the method is very widely used. (IIR and RLE are simply tricks for doing a 1D convolution that produce speedups in some common situations.) -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Gaussian blur: Silly question or buffer error?
Hi,
I may be missing something obvious here, but I'm trying to understand
the workings of the Gaussian Blur plugin, since I need to implement
something similar myself, and either there's something screwy here, or
there's something obvious I'm missing.
In gimp-2.4.4/plugins/common/gauss.c, the gauss_iir() function,
at line 960 we have four pointers initialised - two to the beginning of
their respective buffers, and two to one tuple before the end.
sp_p = src;
sp_m = src + (height - 1) * bytes;
vp = val_p;
vm = val_m + (height - 1) * bytes;
But then the inner loop does this:
for (b = 0; b < bytes; b++)
{
vpptr = vp + b; vmptr = vm + b;
for (i = 0; i <= terms; i++)
{
*vpptr += n_p[i] * sp_p[(-i * bytes) + b] - d_p[i] * vp[(-i *
bytes) + b];
*vmptr += n_m[i] * sp_m[(i * bytes) + b] - d_m[i] * vm[(i *
bytes) + b];
}
...
On the first run through, with b=0, the index [(-i * bytes) + b] will be
negative for all but the first iteration, yet it's used with the sp_p
and vp pointers, which point to the beginning of their buffers, thus
accessing memory outside the buffer. Or am I missing something here?
And while we're on the subject, can anyone point me to an explanation of
the maths behind this IIR approximation of the Gaussian filter? I
understand Gaussian blurring well enough to implement a
convolution-based version, but I want to implement a
local-contrast-stretch filter - basically a gentle large-radius
unsharp-mask, which would require unfeasibly large convolution matrices
to do it that way.
All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no image open spec...
Hi, On Mon, 2008-02-04 at 10:48 +0100, peter sikking wrote: > just to clarify: are you assuming that the whole window will become > transparent and the desktop shines through? No. That would be implementable as there's GTK+ API to do that (though not supported on all platforms). > I am talking about > making some stuff transparent against a window background, hardly > rocket science for GIMP... There's no GTK+ API to do this (yet). Of course if all we have in the window is a background image, then we could make the window background shine through. But I still assume that we will have some useful content in the window. Useful content means GTK+ widgets. And we can't (yet) make GTK+ widgets translucent. Even if this was possible, I still fail to see why this would be useful. To be honest, I am completely baffled to hear such a thing proposed from a user interface professional. What exactly, except for eye candy, is the purpose of this? > the slider is a dead serious key in the whole experience. to seamlessly > track the mood of users over a a working day (or a hobby night) is > worth gold in user interaction. Would you please care to explain this? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no image open spec...
Actually, if "plug-in" means something like a fill pattern that could be user-specified in the same way as the splash screen, I think it would be possible to implement everything Peter has specified here -- including the opacity slider -- using the "scratch image" framework I've been experimenting with. There is one aspect of this specification that seems problematic to me, though. If the user closes the final image by clicking the "X" in the upper right corner of the window, we must close that window or we violate a fundamental rule of window handling. We can create a new window if we feel the need to, but we must close the original window. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no image open spec...
The "no image window" should have a status line, as this provides useful feedback with regard to the hover-over hints of the menu commands. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no image open spec...
I get the sensation that often most trivial solution are overlooked, only because are trivial, even if simple things often work better Users, ( i state as users not as expert of usability) just are used to see graphic sw open with a image windows...i don't thing they will appreciate a special image windows with sliders or peculiar setting. They will appreciate something trivial as gimp opening with a image windows, inside simply a new image,color white, type RGBA, of a default size (something as 600x600 should fit, aside to the toolbox in most of computer screen ,included little as 800x600) That and , for the first time only, a dialog popped up prompting 1 to accept that size or 1 to reset that default size as from users wish OR 3 instead then a blank image start with the last image opened And a short info at end of dialogif the user want change again that default, he may do from Toolbox/preference. That in my opinion and experience as users will solve at best Honestly i can't image any advantage, or anything useful, or even "funny" in that proposed additional Transparency slider . On the contrary i see a related usability problem, if something as that will be done: Users will think that the slider effect may is also rendered in the saved image More if they will forget to reset the slider, they will be easy misleaded.by a effect that is visible, but will be never rendered, (if not by a screenshoot) Alchemie Foto\grafiche - - L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no image open spec...
On Mon, 2008-02-04 at 10:48 +0100, peter sikking wrote: > the slider is a dead serious key in the whole experience. to seamlessly > track the mood of users over a a working day (or a hobby night) is > worth gold in user interaction. You seem to assume that - users will adjust the slider repeatedly - this adjustment somehow reflects their mood (not just lighting conditions from day to night or whatever) I mean to recall that the product vision stresses serious, professional level work. I don't see how playing with such a slider is compatible with a getting-stuff-done mentality. I very strongly doubt that users would adjust it repeatedly, anyway. Then, even if they do: what does it tell us about their mood and what would we do with that information? > the thing to focus here is that GIMP is not going to behave like > some > kid > yelling (yep, that is what a dialog is): "that was fun, what are we > going > to do now... I mean now... really now!" > > as long as we understand that, you will be able to understand the > crucial decisions that I take here. I fail to see how a full size window that is basically empty regarding its informational and interaction aspects could be a good thing. It manages to cover part of the desktop or other windows and distracts from the then only useful bit, the menu. Seen this way, your wallpaper window would yell, too, but it'd be: "BLAH!" The opposite side of "what are we going to do now" would be "see how you get along, I will not raise a finger to help you". -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no image open spec...
Sven wrote: > On Mon, 2008-02-04 at 01:35 +0100, peter sikking wrote: > >> and oh, note that the slider to set the alpha of what goes on in that >> window will be there anyway... > > This is not currently implementable, so I would rather not base the > spec > on this opacity slider. just to clarify: are you assuming that the whole window will become transparent and the desktop shines through? I am talking about making some stuff transparent against a window background, hardly rocket science for GIMP... > I also very much wonder why the window should have something as > useless > as a slider to control the visual appearance the slider is a dead serious key in the whole experience. to seamlessly track the mood of users over a a working day (or a hobby night) is worth gold in user interaction. > but lack any useful widgets > to give people quick access to the things they will most likely do > next. > What's wrong about a link to the recently used images and to the New > image dialog? the thing to focus here is that GIMP is not going to behave like some kid yelling (yep, that is what a dialog is): "that was fun, what are we going to do now... I mean now... really now!" as long as we understand that, you will be able to understand the crucial decisions that I take here. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no image open spec...
On Mon, 2008-02-04 at 09:01 +0100, Sven Neumann wrote: > I also very much wonder why the window should have something as useless > as a slider to control the visual appearance but lack any useful widgets > to give people quick access to the things they will most likely do next. > What's wrong about a link to the recently used images and to the New > image dialog? Same here. I think such a slider would be a waste of both developer and user time (a _million_ users wondering: ooh, what does this slider do? ... to never touch it again ;) Reasons against having Recent/New in the window: - "visual noise" - both are in the file menu already and duplication would lessen consistency in interaction / work against habituation. But then I would prefer a window as narrow as possible, not much more than just a title and a menu bar. Any image would get old soon and putting effort into exchanging it frequently would be wasted. Reasons for having Recent/New in the window: - fast access to the only 2 things a user might want to do (well, there's also accessing preferences) - avoiding a mostly empty window which will trigger uncountable complaints through all eternity ;) The audio application Ardour has a startup dialog with New and Open Recent tabs. The dialog has its issues, but feels very useful. I never use a file manager to open a project there. For GIMP, it should be possible to have New and Recent side by side. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no image open spec...
Hi, On Mon, 2008-02-04 at 01:35 +0100, peter sikking wrote: > 4) a plugin system for this window; we ship a standard, good one like > above. If somebody really insists he or she wants to see a file > open dialog every time or the 10 last edited pictures (both not very > good ideas to force upon one million users) then let them write a plugin > to do that. We certainly don't have so much developer time at hand to design, implement and maintain a plug-in system to add gimmicks to this window. We absolutely need to find a solution here that works for everyone. Delegating this question to a plug-in system is not going to work here. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] no image open spec...
Hi, On Mon, 2008-02-04 at 01:35 +0100, peter sikking wrote: > and oh, note that the slider to set the alpha of what goes on in that > window will be there anyway... This is not currently implementable, so I would rather not base the spec on this opacity slider. I also very much wonder why the window should have something as useless as a slider to control the visual appearance but lack any useful widgets to give people quick access to the things they will most likely do next. What's wrong about a link to the recently used images and to the New image dialog? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
