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' * 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 http://code.google.com/p/gil-contributions/ .
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. Cheers, Nicolas.