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 modes. 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. Lubomir