Re: Request for comments: imread and imwrite

[John Swensen]

On Oct 8, 2010, at 1:02 PM, Judd Storrs wrote:

> On Fri, Oct 8, 2010 at 9:37 AM, John Swensen <address@hidden> wrote:
>> 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.
> 
> As far as image compatibility goes, my personal opinion is that the
> bitstream on the disk doesn't matter. If matlab should be expected to
> read the image correctly (do not put any serious effort into not
> duplicating bugs), and octave can read the images Octave writes using
> it's imread, then it doesn't matter if the bits written by the octave
> and matlab of imwrite are identical.
> 
>> 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.
> 
> Frankly, that would be relying on undocumented matlab behavior that
> could changed by mathworks without notice. Porting to octave would be
> equivalent to porting to a hypothetical future matlab. It wouldn't be
> wrong to fix the code that relies on the index size, either.
> 
> Now, on the other hand, if I tell imwrite to use a specific colormap,
> it should use it. (It's been a long time since I've used either
> colormap files or matlab so I don't even know if that is available). I
> don't really have much sympathy for programmers that rely on
> unspecified default behavior. It's a learning moment for them.
> 
> 
> --judd

Thanks for your comments.  I have concluded that I am first going to work to be 
compatible in the sense that all formats and format specific parameter are 
supported.  Having this as the only constraint, it may be possible for imread 
to read in an image that would have been an indexed image in Matlab, but is a 
non-indexed image in Octave.  People can complain to me at a later time if they 
think it needs changed and simply use ind2rgb and rgb2ind in the meantime.

Here is the list of simple rules I am going to apply when writing images so 
that there is a logical way to interpret how images will be written to disk in 
Octave:
1) When a colormap is not specified, double values are always mapped from (0,1) 
to (0,255) with values greater than 1 being mapped to 255.  If 16 bit output is 
specified explicitly (as is possible for JPEG, PGM, PPM, and PNG) then this is 
(0,1) to (0,65535).  Matlab varies on how it does this based on the file format 
(e.g. BMP does map (0,1) to (0,255), but GIF floors the pixel values). I 
haven't checked all the formats yet, but will implement as I explained.

2) When a colormap is specified, double values are converted to colormap 
indices using uint8(idx-1) as specified in the Matlab documentation

3) Let the *Magick software determine how to store the image on disk as either 
a PseudoClass (image with colormap) or DirectClass (image with explicit pixel 
values) and the size of the colormap if present.  Matlab will still be able to 
read all these files in correctly, however whether they are indexed images or 
RGB images may differ from files written by Matlab because of how they are 
written from Octave via *Magick.

4) Don't preclude "extra" functionality that doesn't break compatibility.  Two 
examples: (1) Matlab doesn't allow color GIF images, except through using a 
colormap, but it is easy to accept a mxnx3 for color gif images) and (2) Matlab 
doesn't allow appending multiple images to a GIF in a single call to imwrite, 
but they do allow appending multiple images to a TIFF and I see no reason to 
disallow it for GIF.

Does anyone else have any problems with these initial simplifying assumptions?  
If not, then I will proceed with this set of rules and we can change later with 
specific requests.

John Swensen