Re: [boost] [gil] New IO release

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