Re: [boost] gil::io "non-review" (was: [gil] Can not open test.jpg)

Subject: Re: [boost] gil::io "non-review" (was: [gil] Can not open test.jpg)
From: Christian Henning (chhenning_at_[hidden])
Date: 2010-03-25 11:49:34

Hi Phil,

>
> Well, have a look at read_rows().  Say one of the jpeg_read_scalines() calls
> fails and calls the error handler.  I think that:
>
> - The dtor for buffer will not be called because you have longjump()d out of
> its scope.

Agreed. I wonder how I can fix that. I cannot really move buffer into
class scope since I don't know the buffer's value type. This type
depends on the current pixel type.

> - jpeg_destroy_decompress() will be called twice, once in raise_error() and
> again in ~jpeg_destroy_decompress() when the exception propagates up.

Fixed.

>
>>> Does someone has an idea how to deal with multi-threaded scenarios?
>>
>> The jpeg_compress_struct (and its friends) has a void* client_data.  If
>> you make the jmp_buf a local variable and pass it through to the error
>> handler using that field then I think everything should be OK?
>
> Just put 'this' in client_data and put the jmpbuf in your object.

Done. I should have thought of this myself.

>
>
> (As I think I suggested before, to me personally it would be more useful to
> have a set of wrappers for these libraries that only deal with these
> C++-ification issues, rather than the full gil integration that you're
> offering.  For example the whole issue with memory usage where you're saying
> that "memory is cheap, everyone has gigabytes these days" just doesn't apply
> to the digital photo frames and mobile phones that I'm dealing with.  So in
> order to get anything useful from this, I would love to decouple this
> 'library wrapping' from the gil aspect.)

When you C++-tified libjpeg for instance, in what container would you
store the data? You probably would use a template parameter to give
the user the option. I do exactly the same. GIL is based on concepts
and so it lets you define your own image type if you like. For
instance when you deal with huge images you might want to create your
own image type that deals more efficiently with memory.

Also, how would a C++ wrapper help you with large images?

All in all, Phil, thanks a lot for help. It has more than helpful!!

Regards,
Christian