Re: Selective Gaussian -> Early test app posted

Eric Grange wrote:
> to attachments.
>
> Includes ability to generate a test noise bitmap, load a test JPG/BMP
> bitmap, perform noise reduction with a reference algorithm and an
> experimental one and then construct a bitmaps with the per-pixel delta
> between the two.

Okay, looks like a good start.

> Notes:
> - parameters are currently hardcoded

I hope this will change. ;)

> - if you don't have an AMD CPU, it will crash until you deactivate the
> hardcoded call to 3DNow optimized version (sorry)

That's not a problem here.

> - gives some rough timing and deviation figures (metrics to be
> refined)

Okay, I think it would be a good idea to store this in some report (together
with the input parameters used, and the size of the image).

> - includes source for a 128 bit version, though the Graphics128 unit
> isn't included (if enough participants are willing to go the 128 bit
> way, I'll probably included, for now this is for eyes only).

I'm willing to participate if the target bitmap format is 32 bit. I think if
we want to have 128 bit bitmaps as a target, then we should consider this a
separate sub-challenge.

A small sidenote: we are planning to add support for 128 bit bitmaps to the
Graphics32 library (as well as other bitmap formats). It is not unlikely
that this will be added when version 2.0 is announced. However, before that,
version 1.8 must be released -- which includes a lot of new features too.

> Purpose isn't as much to benchmark things yet, but rather to get
> started on specifics and requirements such as:
> - should the function operate on bitmaps or on rasters/scanlines?

I was going to say that I would favour an approach where a custom graphics
library (e.g. Graphics32) could be used. However, thinking about it, I see
how it might be difficult to support this option in a generic benchmark
application (unless we allow various function signatures).

If you have a routine that operates on scanlines, then you can easily make
this routine work in Graphics32 too, by simply using a wrapper routine. In
that regard I think scanlines is a good option. Of course, this means I
would have to rewrite my current routines that rely heavily on GR32 -- so in
that regard it's not a good option. ;)

> - should it operate on 32 bits and produce 32 bits, or on 128 and
> produce 128? (ie. work well on 16bits TIFF and not lose precision
> for subsequent sharpening/constrast/whatever PP)

I think we will get more participants if we choose the first alternative.
However, I would rather see two sub-challenges.

> - should the matrix/kernel be passed to the function (and thus assumed
> arbitrary) or should the function compute its own?

Well, the problem with an arbitrary kernel, is that it imposes a constraint
on the kind of optimizations you can perform. Since the gaussian kernel is
separable, you can take advantage of this fact in order to speed up the
implementation. If we assume an arbitrary kernel, then we can no longer
assume that it is still separable.

I think I would rather have the routine manage the kernel all by itself. The
parameters should IMO be restricted to the radius and the threshold value --
since these are the only parameters adjustable by the user in softwares such
as GIMP and Photoshop, and since it would be really difficult to design a
proper benchmark program with even more parameters.

> - is the current reference implementation numerically correct?

Well, as I pointed out in one of my previous posts -- the gaussian has
infinite extent. Hence, if you wanted 100% accuracy, then you should sum up
each pixel in the entire bitmap for each pixel coordinate. However, at a
certain radius the contribution of a pixel value becomes insignificant and
in this case you can safely assume the weight is zero without any impact on
the final result. I don't know what threshold value is used in GIMP, but it
might be worth taking a closer look at this.

> Also should the function support tiling/banding?
>
> This somewhat affects the bitmap vs scanlines and 32 vs 128 bits
> issues, as scanlines provide implicit support for banding, banding
> allows to process only part of the image at a time, and that
> considerably lessens the memory usage issues of 128 bits... (no need
> to have the whole bitmap converted to 128 bits anymore).
> 128 bits makes SSE usage straightforward, 32bits makes SSE2 compulsory
> (but is it an issue? are there many CPUs out there that support SSE
> and do not support neither 3DNow nor SSE2? Are they worth cattering
> to?).

I guess in order to see the advantage of this, we need rather large bitmaps?
Is it possible to determine an ideal size of each tile depending on the
amount of L1 and L2 cache? If we do support banding, does anything else in
the specification have to change (assuming we work with scanlines)?

Mattias













.

Relevant Pages

  • RE: Bitmap displayed in ToolBox of Visual Studio for a control
    ... populated automatically in the Toolbox and the component appears under this ... The bitmap next to the component is the default bitmap. ... Microsoft Online Community Support ... where an initial response from the community or a Microsoft Support ...
    (microsoft.public.dotnet.framework)
  • Re: Display a bitmap from Win32, unmanaged code?
    ... related to deleting the underlying bitmap. ... If the image is still be displayed in the PictureBox, ... Microsoft Online Community Support ... You can send feedback directly to my manager at: ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: GDI+ to draw on canvas with alpha channel
    ... have the alpha accumulate in the bitmap. ... Microsoft Online Community Support ... where an initial response from the community or a Microsoft Support ... project analysis and dump analysis issues. ...
    (microsoft.public.win32.programmer.gdi)
  • Re: tcl/tk wish for seismic data display
    ... bringing SU to tcl/tk.So So i need to get support ... from SU data processing people as well.This ... write the data as a bitmap and that can be used by our tcl/tk program. ... The BLT stripchart widget does not need or want a bitmap. ...
    (comp.lang.tcl)
  • Re: How to get an associated file icon without the Alpha Channel i
    ... no reason for keeping it around after the end of the routine anyway, just make the OLE picture object own the handle and there's no ... You don't need to select the colour bitmap into the temporary DC, GetDIBitsjust requires a device context handle rather than ... Rather than filling out the header structure yourself, you can use GetDIBits() to do this for you - have a look at chapter 3 of the ... When you're editing the mask data, you're attempting to operate on it in the same way as the colour data by getting GetDIBitsto ...
    (microsoft.public.vb.winapi)