Re: Request for comments: imread and imwrite

[Judd Storrs]

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