From: Lubomir Bourdev (lbourdev_at_[hidden])
Date: 2006-06-25 12:32:56
>I do not like the current IO scheme.
I agree with you. Our I/O is very low-level. We only handle some of the
most popular image formats, and of these we only handle the most common
There is a lot more that could be done in I/O but, similar to GUI, this
is peripheral to GIL's design objective.
I was against us releasing the I/O extension at all. But how do you try
an imaging library without I/O? One consideration for you guys is,
should you take GIL, whether to take the I/O module as well.
>From the tutorial, it seems that you have to know the image file format
>(jpeg,png,tiff) at coding time...
We used to have methods like read_image that checked the image file
extension and called the appropriate jpeg_read_image, tiff_read_image,
etc. While they are convenient, we removed them from the public
distribution because they were inherently very constrained. If you add a
new module you have to go and add another case to the switch statement,
etc. Another problem with them is that they require you to compile and
link against all available I/O libraries (libjpeg, libtiff, libpng). The
current I/O is more modularized - you need to only link against the file
formats you need.
A better attempt at this (where you can register file format modules
dynamically) is in the works in ASL.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk