[Octave-bug-tracker] [bug #33615] imwrite not taking same colormaps as parameters as MATLAB

[Carnë Draug]

Update of bug #33615 (project octave):

                  Status:               Need Info => Fixed                  
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #4:

The problem was because the given colormap [1 1 1; 0 0 0] does not have enough
colors for the image (indexed) that had values up to 256.

Apparently, Matlab silently fills the colormap with black (RGB 0,0,0). It does
NOT convert the indices without a matching value on the colormap (I checked
reading back the image, and the colormap had been extended, and not the
indices above the colormap that were brought to a valid color)

I have pushed a change (cset 45e325002810) that fixes this. I don't like the
behavior of changing the colormap so I made Octave issue a warning when this
happens.

There is a very very small problem though. Because the way Graphics Magick
works, when reading that image back, it is read as an indexed logical matrix.
This is because the colormap has actually only 2 colors. This is likely to be
a very rare occasion, if the colormap has 3 colors, there is no issue at all.



octave> imwrite([0:1:10], [1 1 1; 0 0 0],'image.tif')
warning: imwrite: MAP has not enough colors. Filling with black
octave> imread ('image.tif')
ans =

   0   0   1   1   1   1   1   1   1   1   1

octave> [a, b, c] = imread ('image.tif')
a =

   0   0   1   1   1   1   1   1   1   1   1

b =

   1   1   1
   0   0   0
   0   0   0
   0   0   0
   0   0   0
   0   0   0
   0   0   0
   0   0   0
   0   0   0
   0   0   0
   0   0   0
   0   0   0
   0   0   0
   0   0   0
   0   0   0
   0   0   0

c = [](0x0)


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?33615>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/