Request for comments: imread and imwrite

[John Swensen]

After the last patch, I have started to work on other formats and have a couple 
of questions and handups about how others feel things should be implemented.  
The core of my question is "how compatible" should I make imread and imwrite 
with Matlab.  To illustrate my question, I will give an example.  When writing 
GIF images, I have found that Matlab *always* writes the GIF out as an indexed 
GIF with every color included in the colormap, regardless of whether the color 
is contained in the image or not.  While this isn't necessarily a problem, as I 
can write the code that handles GIF images to always fill out the colormap, 
there was definitely nothing in the Matlab documentation that indicated this is 
how they actually do things.  So should I try to maintain compatibility at the 
image file level or simply at the out-to-in level?  Here is a sequence of 
commands that result in different behavior between Octave and Matlab

Executed in Matlab
====================
zz = rand(100,100);
zz2 = (zz>0.5);
imwrite(zz2,'testML.gif');


Executed in Octave
====================
zz = rand(100,100);
zz2 = (zz>0.5);
imwrite(zz2,'testOCT.gif');

Then, running 'gm identify -verbose testML.gif' and 'gm identify -verbose 
testOCT.gif' we see that the Matlab generated file has 256 values in the 
colormap and the Octave generated file has 2 values in the colormap.

While I don't think it is impossible to exactly match the behavior of Matlab, 
it is becoming tedious to check how it works with every possible combination of 
file type and allowed parameters and then figure out how to make GraphicsMagick 
match the behavior.  I guess I also want someone with more experience trying to 
match Matlab behavior to tell me if there is an easier way than:
1) Write out images from Matlab with all possible input types and dimensions 
and all possible output types and parameters
2) Use the command line GraphicsMagick utilities to determine the undocumented 
nuances of all combinations
3) Write the spaghetti mess of switches and if-elses in the DLD-FUNCTIONS code 
to match behavior exactly

I know that if I don't match behavior exactly, there will inevitably be some 
code out there written in Matlab that relies on the dimensions of the colormap 
after reading in a file to run correctly (or something akin this scenario) and 
there will be a question (or criticism) about the code not working for Octave.  
So in some sense I would like to make it completely compatible but am dreading 
the process.

John Swensen