Boost logo

Boost :

Subject: Re: [boost] [GIL] image rescale algorithms
From: Nicolas Lelong (rotoglup_at_[hidden])
Date: 2009-09-07 09:46:25

Hi Christian,

thanks for your feedback. I'll try to answer your comments, reordered -
comments to rescaling code first, then comments on other parts of the source
code in my test repo :

* I would like to invite you to format your code with the appropriate
> headers into the boost format. I can help you here.
> No problem, I'd certainly appreciate some help or guidelines on this point.

* Can you use source code from the freeimage project and relabel it
> under the MIT license?

That's a question I already asked myself - but more to the point, I do not
explicitly use FreeImage code 'as-is' - I went into a rewrite/refactor
process on the code. The code I linked is closely related to the FreeImage
source code only in filters.hpp and filter_weight_table.hpp, all other code
is mine only. I shall take a look towards a complete rewrite, or taking bits
and pieces of proven/tested public domain for these parts.

* I would move filters.hpp and filter_weight_table.hpp into your detail\
> folder.

I forgot to do it first hand for 'filter_weight_table.hpp', consider it
done. For filters.hpp, as the constructs it defines are, IMO, not meant to
be in a 'detail' namespace, I thought about letting it live with

* resample.hpp should include filters.hpp.

Does they physically depends one on another ? I think it is not the case (if
it is, it's my mistake) - I'd more incline to have a 'resample_all.hpp'
header to make it easy on users who don't care on compile times - but I may
be nitpicking here.

* for writing test I recommend boost::test/

I agree that boost::tests would be suitable for a proper boost::gil
extension - but for now, the tests are tied to my specific needs, and I
don't plan to use boost::test for my personal developments. Talking about
this, I didn't get many ideas about how to properly unit test the rescale
code. Apart from testing simple width/height results, it would need to test
the source & rescaled image contents, and I don't know how to setup such a
system. Any ideas ?

According to the rest of your comments :

* You have created a clamp_channel_fn. Isn't that the same as gil's
> scoped_channel_value?

hm, I am under the impression that scoped_channel_value provides the min/max
values for channel values, but have no mechanism to enforce that a value is
clamped to these limits. Hence this algorithm. But I may be mistaken and may
have missed an existing way of clamping values to channel limits. I saw
nothing in channel.hpp.

> * You define a vertical_flip algorithm. Did you notice gil's
> flipped_left_right_view?

Yep, in fact it would be 'flipped_up_down_view' - but this algorithm allows
me to suit one of my 'personnal' needs to vertically flip the image memory
representation inplace. Using 'flipped_up_down_view' would make do an image
copy, and hence use twice as much memory.

As, I said, I like your contribution. What do you think of adding it
> to my gil contribution subversion? This is place where people,
> including me, keep their submissions. I would add you as a member
> though you have the access permissions. The URL is
> .

It would be a good idea, I need first to fix the few standing issues
discussed before.

Another idea is to write a freeimage image reader and writer and add
> it to my gil::io_new project. What do you think of that?

It could be possible, but, IMHO, I'm not sure that it would fit in your
io_new extension. My understanding is that your project aims to provide a
'standalone' image input/output library, and tying it to FreeImage may not
be a good idea for a whole set of users. Maybe it would be better as a 'code
snippet' that could used and modified by the people needing boost::gil and
FreeImage. As I lack time, I'll be more willing to concentrate my work on
resampling, that would be a nice extension to GIL, that on this FreeImage
binding code. But feel free to precise your thoughts, I may be able to give
you a hand on this.



Boost list run by bdawes at, gregod at, cpdaniel at, john at