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/extensi...
Interesting ! Did you measure the performance gain you get by using tbb on this ?* Cheers, Nicolas.