[Octave-bug-tracker] [bug #45565] Using imwrite to write an 8-bit iamge to BMP creates a 24 bit image

[Mike Miller]

Follow-up Comment #15, bug #45565 (project octave):

When I open the attached images, I see the following from GraphicsMagick:


$ gm identify *bmp
D2801fullsize_Created by Octave.bmp BMP 480x480+0+0 DirectClass 8-bit 675.1Ki
0.000u 0:01
D2801fullsize_Saved by ImageJ.bmp[1] BMP 480x480+0+0 PseudoClass 256c 8-bit
226.1Ki 0.000u 0:01
foo-octave.bmp[2] BMP 256x100+0+0 PseudoClass 256c 8-bit 51.2Ki 0.000u 0:01


So GraphicsMagick sees D2801fullsize_Saved by ImageJ.bmp and foo-octave.bmp
both as 8-bit 256-color indexed images.

But checking out these files with Python PIL gives differences:


D2801fullsize_Created by Octave.bmp: BMP 480x480 RGB {'dpi': (75, 75),
'compression': 0} [('raw', (0, 0, 480, 480), 54, ('BGR', 1440, -1))] 
D2801fullsize_Saved by ImageJ.bmp: BMP 480x480 L {'dpi': (0, 0),
'compression': 0} [('raw', (0, 0, 480, 480), 1078, ('L', 480, -1))] 
foo-octave.bmp failed: Unsupported BMP compression (1)


If I create a new BMP file with Octave the same size as the working
D2801fullsize_Saved by ImageJ.bmp (480x480) with


octave:1> x = uint8 (randi ([0, 255], 480, 480));
octave:2> imwrite (x, gray (256), "foo.bmp");
octave:3> whos
Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  ===== 
        x         480x480                   230400  uint8

octave:4> system ("ls -l foo.bmp");
-rw-r----- 1 mike mike 461076 Jul 24 01:06 foo.bmp


Don't know why but the saved file is twice the size of the matrix in memory.
The gm utility still claims that it contains 8-bit pixels.

    _______________________________________________________

Reply to this item at:

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

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