Re: [boost] [GIL] image rescale algorithms

Subject: Re: [boost] [GIL] image rescale algorithms
From: Nicolas Lelong (rotoglup_at_[hidden])
Date: 2009-09-10 04:17:41

Hi Est.

Thanks for your feedback ! I recently came across ramenhdr, it looks
promising !

I think filters should be a small separate GIL extension.
> They are useful also for other image resampling algorithms.
>

Yep, I tend to agree with that.

> In clamp_channel_fn I added an overload like this: [...]
> to avoid clamping floating point channels. Another option would be to clamp
> only negative values.
>

Hm, I've not come, yet, to tackle myself the issue of clamping when HDR
floating point channel values come in. I was thinking to create an
appropriate pixel type for unscoped floating point values. The current state
of rgba32f_pixel_t is meant to be scoped in the 0..1 range 'by contract' -
even if GIL does not (currently) implement range checking. Having an
appropriate pixel type should be more future-proof. What do you think ?

> I think
>
> (A) template <typename PixelType>
> struct create_accum_pixel_type : public create_accum_pixel_type<PixelType>
> {};
>
> can be replaced with
>
> (B) template <typename PixelType>
> struct create_accum_pixel_type {};
>

It's certainly more compact, I think I stole the (A) construct somewhere in
GIL, but I don't see what it brings now you talk about it. I'll try to keep
it simple !

I had to add some typenames in front of accum_pixel_t in rescale_rows,
> rescale_cols and rescale to build with gcc.
>

Oops, I currently only build with MSVC8 - glad to see that the problems were
few...

> and I made a parallel version using Intel TBB. It's here:
>
> http://ramenhdr.svn.sourceforge.net/viewvc/ramenhdr/trunk/extern/gil/extension/parallel_rescale.hpp?view=log
>

Interesting ! Did you measure the performance gain you get by using tbb on
this ?*

Cheers,

Nicolas.