Re: [boost] [gil] [announcement] New IO lib

From: John Femiani (JOHN.FEMIANI_at_[hidden])
Date: 2008-05-02 16:14:22

Christian wrote:
> > might know a bit more about libjpeg than me:
> >
> > DCT type: libjpeg lets you select one of three different DCT 
> > implementations via cinfo.dct_method: integer, normal 
> floating point 
> > and a faster floating point algorithm that is less 
> accurate.  I have 
> > found this faster algorithm to be visually 
> indistinguishable and makes 
> > decoding about 1/4 to 1/3 faster overall, and I now use it 
> by default.
> > It would be good to have some way to enable this.
> 
> Interesting. The new IO interface defines a image_read_info 
> type for each file format. The user can use those structures 
> to either get information from the image that is unimportant 
> for the reader or to set some values that can be used by the 
> reader while reading. 
<snip> 
> >
> > Scaled decoding: libjpeg has a mode in which it will scale 
> the image 
> > down to 1/2, 1/4 or 1/8 of its native size while decoding (see 
> > cinfo.scale_num and cinfo.scale_denom).  This is much less 
> expensive 
> > than doing the full decode and then scaling.  It would be 
> good to have 
> > some way of using this.
> 

I think the tiff format, which I beleve was designed to be a kind of
meta-format on top of jpeg and others, has a huge slew of 'tags' that
you can peruse on the web.  I think each tag corresponds tpo som peice
of info. that can be read from or written to the underlying image. These
might be useful for providing the kinds of parameters that could/should
be read or written.

> >
> > Partial image decoding: I see that you have some code to extract a 
> > portion of an image, but that it does this by reading and 
> discarding 
> > the unwanted parts.  You should certainly be able to avoid 
> doing this 
> > for the parts after the wanted portion, as you note in the 
> comments.  
> > I have been trying to work out how to avoid doing this work for the 
> > earlier parts of the image.  It should be possible to skip the 
> > expensive DCT for these parts as libjpeg has a mode in 
> which it will 
> > perform only Huffman decoding and returns DCT coefficients 
> > (jpeg_read_coefficients).  However, I've not found a way to 
> ask it to 
> > do the DCT (and subsequent steps) for the wanted subset of those 
> > values.  I believe that it's also possible to skip lines in 
> the JPEG 
> > data (i.e. not even doing the Huffman decoding) by looking 
> for an FFDA 
> > marker, but I don't see anything in libjpeg to support that.
> 
> I believe the smallest entity to read is by scanline. Because 
> of compression there is no random access for scanlines or 
> parts of a scanline. Though, skipping whole scanlines or 
> parts of scanlines might be problematic. It will require some 
> research some find the right ways. I totally agree on 
> minimizing expensive operations.
> 

I have always thought that an image reader/writer should act a lot like
an image that holds memory for the pixels, except that it could be lazy
about when it allocated. You would create one from a file, but it would
only read the header. You would ask it for its size or other properties,
or request a view to part of the pixels. It would load what was needed
(possibly more) into memory. You would be able to pass a visitor to some
operations and it would call the visitor at various phases of decoding
with format specific info, which may be an array of coefficients, a scan
line, a single-channel-view, or a view to a tile that is smaller than
the region requested.   This way somebody could customize handling of
various kinds of format specific info in a generic way, or just print
progress (% complete) messages. 

for example:

jpeg_image_t jpeg(filename); 

size_t w = get(jpeg, tags::width);
size_t h = get(jpeg, tags::height);
double compression_ratio = get(jpeg, tags::compression_ratio);

struct my_visitor {
        //Swallow unhandled events
        template<class Event, class Data>
        void operator()(Data & data, Event const& event){}

        template<class View>
        void operator()(View & tile, events::on_tile){
                //Do something ....
        }
};

//Request a portion to be loaded into memory somewhere
jpeg_image_t::view_t roi = jpeg.lock_view(x, y, width, height,
my_visitor)

I havent considered all the details, but this kind of interface seems
like 
it would be good, if it works.

-- John