Subject: Re: [boost] [gil] New IO release
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2010-10-17 18:57:58
> "Phil Endecott" <spam_from_boost_dev_at_[hidden]> wrote in message
> news:1286804807448_at_dmwebmail.dmwebmail.chezphil.org...
>> I've had a quick look at your libjpeg interface. Two features that I
>> often use are dct_method=JDCT_IFAST and scaling down 2x or 4x using
>> scale_num and scale_denom. It would be interesting to know whether (a)
>> your existing code lets me use these via a "native handle", or (b) they
>> could be added easily.
>
> Well, w/o trying, I think you should be able to do it straight away with
> option a:
>
> gil::libjpeg_image::reader_for<...>::type your_image( ... );
> your_image.lib_object().dct_method = JDCT_IFAST;
> your_image.lib_object().scale_num = your_scale_num;
> your_image.copy_to.....(...);
Ok, w/ trying it did not work if you tried to copy to an image with
'dimension synchronization' (resizing the target GIL image to fit the JPEG
image) because:
a) the input/original/unscaled dimensions were used to resize the
image/report the JPEG dimensions
b) even if output/scaled dimensions were used it still would not work
because the target image is resized _before_ the start of the JPEG
decompression (when the output dimensions are updated)...
So I just committed a fix to account for both of those issues. The key issue
was to cause the output dimensions to be updated/recalculated (to call
jpeg_calc_output_dimensions()) if the user changes the scale_num value.
There are several ways that this can be handled:
- add an internal flag to libjpeg_image that will be set every time the user
calls lib_object() and will be checked (and cleared) in dimensions() (where
jpeg_calc_output_dimensions() will be called if the flag is set)
- instead of a plain jpeg_decompress_struct reference make lib_object()
return a proxy reference class that will call jpeg_calc_output_dimensions()
in its destructor
- expose a new 'update_output_dimensions()' like member function through
which the user can (and must if relevant changes are made using
lib_object()) deterministically cause the update...
...all of these of course have different compromises between overhead,
'cleanness' and safety...currently I used the first option...
-- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman