Mon 17 Aug 2015 01:59:17 PM UTC, comment #25:
Done. Created a new but report.
|
Mon 17 Aug 2015 01:31:37 PM UTC, comment #24:
Can we keep this bug report on topic?
The fix that was made was to create uncompressed BMP files instead of RLE-compressed BMP files, and that is now working as you've confirmed when you specify a colormap to force the image to be an indexed image.
Your additional observation that the file should be an 8-bit indexed grayscale file when the input is a uint8 was not addressed by the fix made so far. That is an additional change where it appears that Matlab is creating indexed files depending on the image type and the input matrix type. Perhaps a new bug report to keep the discussion from getting confused?
There is nothing wrong with your compilation.
|
Mon 17 Aug 2015 12:59:44 PM UTC, comment #23:
It doesn't appear like the changes to _magick_read_.cc are in the file mxe-octave/pkg/octave-4.1.0+.tar.gz.
Is that normal? If it is, what might the procedure be to update the ...tar.gz files used in the MXE build?
|
Mon 17 Aug 2015 07:34:43 AM UTC, comment #22:
>I can see the changes to imwrite from this bug fix so I should have a good compile of Octave but this is a fresh compile so maybe there is a problem with the compilation.
If you want to check the sources that were complied in mxe build, you can get an archive file: mxe-octave/pkg/octave-4.1.0+.tar.gz.
|
Mon 17 Aug 2015 03:40:02 AM UTC, comment #21:
Carne
I was able to compile up Octave 4.1.0+ (MXE) so I could test the fix on my system.
This seems to work as it should, creating an 8-bit BMP file.
octave> img = uint8 (ones (100, 1) .* [0:255]);
octave> map = gray(256);
octave> imwrite (img, map, "foo-octave.bmp");
If I understand Matlab (maybe I am misinterpreting Matlab)
octave> img = uint8 (ones (100, 1) .* [0:255]);
octave> imwrite (img, "foo-octave.bmp");
should also work but, with Octave, still produces a 24-bit image.
I can see the changes to imwrite from this bug fix so I should have a good compile of Octave but this is a fresh compile so maybe there is a problem with the compilation.
|
Tue 28 Jul 2015 04:49:23 PM UTC, comment #20:
Small correction from my last message, Matlab only supports compressino option for HDF4 format.
|
Tue 28 Jul 2015 04:48:33 PM UTC, comment #19:
Fixed with http://hg.savannah.gnu.org/hgweb/octave/rev/5b8e4f668c53
This adds the compression option to imwrite while defaulting to none. It seems that Matlab only supports the compression method for the jpeg format but this change adds it for a bunch of other formats. If the GM coder does not support it, it defaults to whatever GM wants to do. For example, RLE compression of bmp files only works for indexed images.
|
Sat 25 Jul 2015 04:18:41 AM UTC, comment #18:
Thanks for confirming Mike
|
Fri 24 Jul 2015 11:01:24 PM UTC, comment #17:
Confirmed with Matlab that imwrite creates an uncompressed 8-bit-per-pixel BMP file when the array is of type uint8, no need to specify a colormap. Also confirmed that Matlab creates an uncompressed 1-bit-per-pixel BMP image when the array is logical. In both cases the file is an indexed image file with implicit grayscale colormaps.
Updating to confirmed and Matlab compatibility.
|
Fri 24 Jul 2015 09:49:58 PM UTC, comment #16:
So I analyzed the BMP header fields more closely and found that Octave creates a BMP using RLE compression by default, while the file you have attached that you say works is not using any compression. This agrees with the info I saw from PIL.
So my simple thought at this point is that Octave needs to tell GraphicsMagick to write uncompressed BMP files, if GraphicsMagick exposes that knob and allows a way for Octave to set that. This seems like a Matlab compatibility item, based on https://www.mathworks.com/help/matlab/ref/imwrite.html saying that BMP files are always uncompressed.
This is independent of whether imwrite with a uint8 argument should write 8-bit BMP files by default or whether it requires a colormap argument. I can't decipher Matlab's help page for imwrite to figure out if that's a separate compatibility issue.
|
Fri 24 Jul 2015 05:19:00 AM UTC, comment #15:
When I open the attached images, I see the following from GraphicsMagick:
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:
If I create a new BMP file with Octave the same size as the working D2801fullsize_Saved by ImageJ.bmp (480x480) with
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.
|
Mon 20 Jul 2015 04:00:41 PM UTC, comment #14:
Attached foo-octave.bmp which , under Windows has a bit depth of 32
(file #34469)
|
Mon 20 Jul 2015 03:26:15 PM UTC, comment #13:
Can you also attach foo-octave.bmp that doesn't work for you, as created with imwrite(img, map, "foo-octave.bmp")?
|
Mon 20 Jul 2015 03:19:33 PM UTC, comment #12:
Thanks Carne for looking at this.
It seem that this must be related to Octave under Windows.
When I execute ( I am not sure how to insert of code block in the comment)
octave> img = uint8 (ones (100, 1) .* [0:255]);
octave> map = gray(256);
octave> imwrite (img, map, "foo-octave.bmp");
octave> exit
The resulting image has a bit depth of 32 and when I try and open it in ImageJ I get a "Compression Not Supported" error. 32 is an odd bit depth.
Executing
octave> imwrite (img, "foo-octave.bmp");
produces and image with a bit depth of 24.
|
Mon 20 Jul 2015 09:27:20 AM UTC, comment #11:
Also, I have reported the bug I mentioned on comment #5 against bioformats.
|
Fri 17 Jul 2015 02:38:35 PM UTC, comment #10:
Mike Miller solution works for me:
|
Fri 17 Jul 2015 02:31:41 PM UTC, comment #9:
Here are a couple of images I am actually working work.
The file "D2801fullsize_Saved by Octave" was an 8bit image saved by Octave using imwrite with a gray map.
The file "D2801fullsize_Saved by ImageJ" was the same file opened in ImageJ converted to 8bit and saved.
In the application I am using, the Octave image gives and Image Size Error while the ImageJ version works correctly.
(file #34458, file #34459)
|
Fri 17 Jul 2015 02:16:53 PM UTC, comment #8:
Certainly. Appreciate the help.
I have uploaded 2 image a "correct" 8-bit BMP image (created by ImageJ) and RGB image created by imwrite in Octave using
imwrite (ind2gray (a, map), "foo.bmp");
It looks like the imwrite is creating all three channels even when there is only one.
(file #34456, file #34457)
|
Fri 17 Jul 2015 01:34:04 PM UTC, comment #7:
Ian, can you post an example of an 8-bit BMP that works with the application you are targeting? That may help give an idea of what you're trying to achieve.
Do you know if the application expects each 8-bit pixel to represent a color (or grayscale) value or rather an index into a color table? That would also be useful information.
|
Fri 17 Jul 2015 01:25:03 PM UTC, comment #6:
Although that allows it to be opened in ImageJ, the image, when opened in ImageJ, is an RGB Image. The application I an trying to use the images in requires a 8 bit BMP file.
I was just using ImageJ to test the image.
|
Fri 17 Jul 2015 01:11:59 PM UTC, comment #5:
Actually, if you enable ImageJ's SCIFIO2, or use the bioformats importer, then ImageJ will open the file.
However, you can use the following which works fine in ImageJ, even when using plain ImageJ 1.
|
Fri 17 Jul 2015 12:59:59 PM UTC, comment #4:
The program that the images are destined for requires 8bit bmp files
I was hoping the solution proposed by Mike would work but when I try to open the saved image in ImageJ, I get a "Compression Not Supported" error so there is something wrong with the file created that way.
Although I wouldn't know for sure that BMP files are always supposed to be indexed images, I have always been able to save the images as 8bit bitmpas in other programs.
|
Fri 17 Jul 2015 10:21:51 AM UTC, comment #3:
This bug (or lack of it), may be dependent on the version of Graphics Magick installed.
I can see a bug with it but different from the one originally reported:
If a bmp file is always an indexed image (is this true?), then it should have returned a colormap.
|
Fri 17 Jul 2015 02:50:27 AM UTC, comment #2:
Thanks for your bug report. AFAICT this is working correctly. If I understand the BMP file format correctly, 8-bit BMP files are indexed images. To create an indexed image with imwrite, you must specific a colormap (palette) argument.
For example, this creates an 8-bit BMP file for me:
Am I understanding this correctly?
|
Thu 16 Jul 2015 10:15:57 PM UTC, comment #1:
When trying to write an 8-bit image to a BMP file, the image ends up as a 24-bit image. This is not a problem with jpg and tif file format.
a = repmat (uint8 (0:255), 100, 1);
imwrite (a, "test.jpg");
imwrite (a, "test.tif");
imwrite (a, "test.bmp");
|
Thu 16 Jul 2015 10:10:29 PM UTC, original submission:
|