RSS/Atom feed Twitter
Site is read-only, email is disabled
  1. Chat
  2. Useful links
  3. Polls

Featured content

Gimp-developer Digest, Vol 73, Issue 16

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.

4 of 5 messages available
Toggle history

Please log in to manage your subscriptions.
mailman.3.1223233204.11197.... 07 Oct 20:26
  Gimp-developer Digest, Vol 73, Issue 16 Stephen DeLear 06 Oct 07:13
   Gimp-developer Digest, Vol 73, Issue 16 Hal V. Engel 06 Oct 17:36
   Gimp-developer Digest, Vol 73, Issue 16 Alexandre Prokoudine 09 Oct 14:43
    Gimp-developer Digest, Vol 73, Issue 16 Øyvind Kolås 09 Oct 15:42
Stephen DeLear
2008-10-06 07:13:47 UTC (over 16 years ago)

Gimp-developer Digest, Vol 73, Issue 16

Alexandre

Not to be smarmy but:

operation_class->name = "sdv-unsharp-mask";

and leave the standard unsharp mask.

The current unsharp mask uses radius, amount and threashold. The new one uses scale and standard deviation. The function it is performing an unsharp mask but it's done the equivalent of going from Farenhight to Kelvin without telling anyone. This results in somebody using one image editor not being able to spec actions for somebody using a different editor. This can be a big deal where multiple photographers are trying to produce a consistent output (for example a primary and secondary shooter at a wedding).

As for Qtpfsgui, the autoalign doesn't work, even on tripod mounted shots on a still day.

On Sun, Oct 5, 2008 at 9:28 PM, Stephen DeLear wrote:

Unsharpen Mask: The GEGL unsharpen mask feature does not use standard terminology. I have no idea how to set this.

Let me give you an idea: edit the source code and send us a patch ('diff -u' is your friend)

You want this file:

http://svn.gnome.org/viewvc/gegl/trunk/operations/common/unsharp-mask.c?revision=2590&view=markup

:-)

High Dynamic Range Imaging: Which will require greater then 8bit color. Mathematically putting 3 or more images bracketed on a tripod together for an expanded tonal range. Currently can be done natively in CS3/CS4.

Qtpfsgui is your friend :-)

Noise Reduction: The overexposed look is in for photography lately as

dark

areas of an image pick up patterning from the digital sensor (i.e. noise). Back in the days of film seeing grain in an image enlarged to several feet would be a "live with it". Today a number of companies will

reject images

showing ANY noise at 100%. Plugins such as noise ninja are quite popular. Would be nice to have a specific noise killing enhancement in GIMP.

You mean you want all those noise reduction plug-ins and scripts floating around GIMP in the bundle or some particular one? Could you probably be more particular about that? :-)

I'm not saying GIMP developers will do what you say (I'm not in position to make any claims regarding development process), but at least you could start with review of existing solutions for GIMP (GREYCstoration, Wavelet Denoise etc.) with samples and recommendations. That would be a good start. Just telling people something is missing and not providing enough information is not quite helpful ;-)

Alexandre

Hal V. Engel
2008-10-06 17:36:42 UTC (over 16 years ago)

Gimp-developer Digest, Vol 73, Issue 16

On Sunday 05 October 2008 22:13:47 Stephen DeLear wrote: snip

As for Qtpfsgui, the autoalign doesn't work, even on tripod mounted shots on a still day.

You might want to give Hugin a try for creating an HDR image from an stack of images. With it you can select control points to make image alignment very precise and it will output high bit depth image files.

Hal

Alexandre Prokoudine
2008-10-09 14:43:36 UTC (over 16 years ago)

Gimp-developer Digest, Vol 73, Issue 16

On Mon, Oct 6, 2008 at 9:13 AM, Stephen DeLear wrote:

operation_class->name = "sdv-unsharp-mask";

and leave the standard unsharp mask.

The current unsharp mask uses radius, amount and threashold. The new one uses scale and standard deviation. The function it is performing an unsharp mask but it's done the equivalent of going from Farenhight to Kelvin without telling anyone. This results in somebody using one image editor not being able to spec actions for somebody using a different editor. This can be a big deal where multiple photographers are trying to produce a consistent output (for example a primary and secondary shooter at a wedding).

Ah, I see what you mean. That's a question to author of the GEGL op then.

As for Qtpfsgui, the autoalign doesn't work, even on tripod mounted shots on a still day.

Qtpfsgui uses align_image_stack from hugin to do it. If you say that Qtpfsgui doesn't work, that means that hugin doesn't align stack of images either, right? :-)

Alexandre

Øyvind Kolås
2008-10-09 15:42:18 UTC (over 16 years ago)

Gimp-developer Digest, Vol 73, Issue 16

On Thu, Oct 9, 2008 at 1:43 PM, Alexandre Prokoudine wrote:

On Mon, Oct 6, 2008 at 9:13 AM, Stephen DeLear wrote:

operation_class->name = "sdv-unsharp-mask";

and leave the standard unsharp mask.

The current unsharp mask uses radius, amount and threashold. The new one uses scale and standard deviation. The function it is performing an unsharp mask but it's done the equivalent of going from Farenhight to Kelvin without telling anyone. This results in somebody using one image editor not being able to spec actions for somebody using a different editor. This can be a big deal where multiple photographers are trying to produce a consistent output (for example a primary and secondary shooter at a wedding).

Ah, I see what you mean. That's a question to author of the GEGL op then.

The names of properties of GEGL operations are as far as I am concerned API, when creating a user interface in a photo manipulation application like GIMP, f-spot or other applications on top it would be the responsibility of the programmer to map the scientific terms used to describe the properties to sliders that maybe uses terms more useful to a casual non expert image processing person. Using the standard deviation instead of an approximate radius of the gaussian blur is much more mathematically correct and is also the way the SVG 1.2 filter specification specifies the parameters for a gaussian blur.

/Øyvind K.