On 18-12-10 12:58, g...@catking.net wrote:
On 17/12/10 20:23, Liam R E Quin wrote:
On Thu, 2010-12-09 at 09:35 +1100, Jan Smith wrote:
Hi,
What are the best GIMP tools for sharpening?
Is there a time when someone would use Sharpen instead of Unsharp Mask? To
me GIMP's Unsharp Mask has a
On 24-08-10 11:51, Øyvind Kolås wrote:
On Tue, Aug 24, 2010 at 9:58 AM, Rupert Weberg...@leguanease.org wrote:
On 08/24/2010 04:20 AM, David Gowers wrote:
I hope you're not associating the quite suboptimal way in which GIMP
currently uses GEGL, with BABL's speed or lack of speed.
BABL just
Compile and end-user. Not all en-users compile their version of Gimp.
Bumping the version number in XCF and implementing the compatibility would
probably be better.
- Originele e-mail -
Van: Charlie De charlieco...@yahoo.com
Aan: gimp-developer@lists.xcf.berkeley.edu
Verzonden:
Alastair M. Robinson wrote:
Hi
Sven Neumann wrote:
As already explained in my previous mail, the decimation routines are
only used for the pre-scaling steps. As soon as the image is close
enough to the final size, the chosen interpolation routine is used. This
gives continuous results
Sven Neumann wrote:
Hi,
On Thu, 2008-08-28 at 22:38 +0200, Geert Jordaens wrote:
What are your doubts with the new code? Why would a simple box-filter be
better for decimating?
My doubts with the current approach are manifold:
The current code has decimation routines
Sven Neumann wrote:
Hi,
after spending quite some time with the new scale code, I have some
doubts about the way that it is scaling down. So here's a patch that I
am playing with at the moment:
http://sven.gimp.org/misc/gimp-decimate.diff
This patch applies against SVN trunk. It only
Sven Neumann wrote:
Hi Geert,
I have a small patch to scale-region.c that I would to have your opinion
on. I noticed that the current code sometimes does an unneeded copy
operation. This happens when the scale factor is 2^n. For example when
an image of 800x600 pixels is scaled to 400x300.
David Gowers wrote:
Hello. I've just completed the first half of the set (all specified
results before the patch). Currently image files total 66mb, I'm
guessing after adding the results after-patch this will come up to
~110mb. During this testing I found one obvious bug, it remains to be
I was browsing trough the buffer coding in svn and noticed following in
*gegl-buffer-load.c
http://svn.gnome.org/viewvc/gegl/trunk/gegl/buffer/gegl-buffer-load.c?view=log
*Is it normal that the width and height parameters are inversed?
GeglBuffer *
*gegl_buffer_load* (*const* gchar *path)
{
Øyvind Kolås wrote:
On 8/9/07, Graeme Gill [EMAIL PROTECTED] wrote:
Øyvind Kolås wrote:
This code implements a perfect box filter for this case, what needs to
be added on top
of this to be able to do good estimate (maybe even exact) box filter
resamplings is trilinear interpolation
David Gowers wrote:
On 8/7/07, Geert Jordaens [EMAIL PROTECTED] wrote:
I can't seem to find the associated bug. Does anybody know which is the
bug report?
I've got a test version (for scale-funcs.c) that scales down in reducing
the image 1/4 each step.
Between each step a the image
[EMAIL PROTECTED] wrote:
On Wed, 08 Aug 2007 11:57:00 +0200, Geert Jordaens
[EMAIL PROTECTED] wrote:
I did some reading on image pyramid's (googling) and there the blur
action is described as a low pass filter.
Factoring the blur out is not a problem. I also have to look to the
non
Sven Neumann wrote:
Hi,
On Mon, 2007-08-06 at 13:27 -0300, Guillermo Espertino wrote:
You're absolutely right. This discussion is pointless. If you suggest
that a script for scaling down in several steps is a valid solution you
know as much about image manipulation as I do about
David Gowers wrote:
On 6/23/07, Sven Neumann [EMAIL PROTECTED] wrote:
Hi,
On Sat, 2007-06-23 at 13:26 +0200, [EMAIL PROTECTED] wrote:
I think nearest neighbour is non technical, very obvious in it's meaning
and readily understood.
IMO it is very technical and the vast
-developer
IMHO this comes from the histogram correction, try the same with a black
(00) cross and white (FF) background.
see :
2004-10-30 Sven Neumann [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
* plug-ins/common/despeckle.c: applied a patch from Geert Jordaens
:[EMAIL PROTECTED]
* plug-ins/common/despeckle.c: applied a patch from Geert Jordaens
that improves the Despeckle algorithm. See bug #72862
http://bugzilla.gnome.org/show_bug.cgi?id=72862.
Right now I don't have the tme to followup a bug report or create a complete
patch
For info on different technics of handling the edge you could always
have a look at :
http://www.cs.cornell.edu/Courses/cs465/2003fa/lectures/04filt-resamp/
Geert
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
Hello,
just to say I'm still working on the lanczos scaling however I can only
work limmited time on it.
Geert
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Pasi Savolainen wrote:
Hi,
I'm trying to find a median filter for GIMP and have been having some
difficulties. From what I've gathered with google, despeckle plugin is
the one that I should look at.
I think that it should be ran in non-adaptive and non-recursive mode
with white/black points se
Hi,
if we where to write a vfs for gimp the links below provide some basic
information.
Anyway it helped me to understand the thread.
http://www.flipcode.com/articles/article_vfs01.shtml
http://koti.mbnet.fi/heitsu/vfs
Geert
___
Gimp-developer mailing
yesterday there was a discussion going on about fourier transform.
Before the feature freeze for Gimp 2.2 i was working on a wiener filter
plugin.
This filter uses a fourier transform. A first version is available at
http://users.pandora.be/geert.jordaens/wiener/
I also started on writing a
hello,
I'm trying to catch up with the changes concerning the preview widget
Could somebody explain me why the functions
gimp_preview_area_menu_popup
gimp_preview_area_menu_new
gimp_preview_area_menu_toggled
are located in gimppreviewarea this way the preview area is not a basic replacement
David Odin wrote:
On Tue, Sep 14, 2004 at 07:42:18PM +0200, geert jordaens wrote:
hello,
I'm trying to catch up with the changes concerning the preview widget
Could somebody explain me why the functions
gimp_preview_area_menu_popup
gimp_preview_area_menu_new
David Odin wrote:
On Tue, Sep 14, 2004 at 10:23:10PM +0200, geert jordaens wrote:
why not just using GimpPreviewArea in a frame? :
Well applying a plugin on a 3000*2000 pixel image could take a lot of time.
Making the preview scrollable and applying the effect on the viewable
part solves most
I'll comment on this one here since I cannot attend the GimpCon.
Splitting up as discussed on the mailinglist before:
1. a completely passive widget that has no other function then to
visualize a preview image.
See bugzilla http://bugzilla.gnome.org/show_bug.cgi?id=144759.
The API
I'll comment on this one here since I cannot attend the GimpCon.
Splitting up as discussed on the mailinglist before:
1. a completely passive widget that has no other function then to
visualize a preview image.
See bugzilla http://bugzilla.gnome.org/show_bug.cgi?id=144759.
The API
PLEASE,
has this still anything to do with the original subject?
I've got a suggestion :
when offended by a mail/comment whatever, don't reply immediatly. Go to
a window (not gimp) open it Yell as hard as you can.
Take five minutes and repeat if necessary. Then go back to your mail
write it,
Agree with Ernst that it's not bad to have the preview widget hold data
like other then it's physical limits :
- scale
- selection limits
- ...
For instance you can have a plug-in that displays 2 scrollable previews
one showing the before and one the after effect.
Even nicer they could have
maybe this issue can be solved sportively during a boxing match on the
GUADEC conference. ;-)
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
I think come up with a simple preview widget is the way to go. At least
all people willing to
add preview's could start doing it the same way.
What I've seen from plugin's is that they are frequently using pixel
regions to render images.
If the pixel region isn't generic enough the I would
staring from the back.
Again, sorry, but I don't understand this. What's the displayed area?
What do you mean when you say render
We are talking about a preview therefore the (displayed)preview area is
the area that is visible to the user.
Will use in for further explanation preview buffer to
Sven Neumann wrote:
Hi,
geert jordaens [EMAIL PROTECTED] writes:
A minimum for the preview widget would be :
Widgets :
1. The preview area
2. Horizontal/Vertical scrollbars if needed.
agreed
Signals :
1. preview_draw : draw preview area from
Sven
We can keep the buffer outside the preview widget and only have it
create an internal buffer if no external buffer is supplied. The API
I have in mind is something like the following:
/**
* Set a pointer to an external buffer.
*
* The buffer will be of type guchar* for now but using a
Sven
ignore the previous posting
We can keep the buffer outside the preview widget and only have it
create an internal buffer if no external buffer is supplied. The API
I have in mind is something like the following:
/** * Set a pointer to an external buffer.
*
* The buffer will be of type
hello,
this is the first time I'm posting on this list. It realy is the gimp
developer list?
I've modified the unsharp plugin and added a preview functionality to it.
How do I share it, do I sent it to someone for review?
kind regards
Geert Jordaens
35 matches
Mail list logo
