Re: [boost] [GIL] image rescale algorithms

Subject: Re: [boost] [GIL] image rescale algorithms
From: Christian Henning (chhenning_at_[hidden])
Date: 2009-09-10 10:38:44

Nicolas,

> * 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'm have really no idea if that's good enough or not. We could ask the
freeimage people.

>
> 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.

resample_all is good enough, I believe.

>
> * 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 ?
>
For writing a gil extension I recommend boost::test. There is really
no need to introduce another testing framework. For your own code, you
can do what's best for you, of course. ;-)

>> * 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.

vertical_flip is up_side_down? Mhmm, is it just me or is this counterintuitive?

>
> 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.

Let me know how it goes.

>
> 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.

The io_new extension depends already on libjpeg, libpng, and libtiff.
FWIW, a potential freeimage extension should have the same interface
as the current io_new interface. That's why I thought of adding it to
io_new. On the contrary, image magick might be even better since has
many more formats. Just to get the gil::io stuff over and down with. I
mean boost would have all the necessary formats available.

Regards,
Christian