imread.m fails reading/writing 16bit images correctly

[John W. Eaton]

On 29-Jun-2009, Benjamin Lindner wrote:

| using current development sources on mingw32, together with 
| graphicsmagick-1.3.5 configured with --quantum-depth=16, imread does not
| correctly read 16bit images.
| 
| octave.exe:2:C:\> imwrite(uint16(12345),"test.tiff");
| octave.exe:3:C:\> img=imread("test.tiff")
| img = 48
| octave.exe:4:C:\> class(img)
| ans = uint8
| octave.exe:5:C:\> imfinfo("test.tiff")
| ans =
| {
|   Filename = C:\test.tiff
|   FileSize =  261
|   Height =  1
|   Width =  1
|   BitDepth =  16
|   Format = TIFF
|   LongFormat = Tagged Image File Format
|   XResolution = 0
|   YResolution = 0
|   TotalColors =  1
|   TileName =
|   AnimationDelay = 0
|   AnimationIterations = 0
|   ByteOrder = undefined
|   Gamma = 0
|   Matte = 0
|   ModulusDepth =  13
|   Quality =  75
|   QuantizeColors =  256
|   ResolutionUnits = undefined
|   ColorType = grayscale
|   View =
|   FileModDate = 29-Jun-2009 11:40:51
| }
| 
| The reason (I believe) is that __magick_read__.cc (staring at line 418) 
| determines from ModulusDepth the number of bits required to store image data 
| into incorrectly.
| With the above Modulusdepth=13, the calculated bitdepth is 8, when it should 
| be 16.
| 
| The attached changeset fixes this, but it still does not work correctly.
| 
| octave.exe:5:C:\> imwrite(uint16([12345,12346,12347]), "test2.tiff");
| octave.exe:6:C:\> img=imread("test2.tiff")
| img =
| 
|   12344  12345  12346
| 
| the values read are off-by-1.
| 
| And apparently they are already written off-by-1
| 
| c:\> tiffinfo -d test2.tiff
| TIFF Directory at offset 0xe (14)
|   Image Width: 3 Image Length: 1
|   Bits/Sample: 16
|   Sample Format: unsigned integer
|   Compression Scheme: None
|   Photometric Interpretation: min-is-black
|   Samples/Pixel: 1
|   Rows/Strip: 1365
|   Planar Configuration: single image plane
|   Page Number: 0-1
|   DocumentName: test2.tiff
|   Software: GraphicsMagick 1.3.5 2009-01-26 Q16 http://www.GraphicsMagick.org/
| Strip 0:
|  38 30 39 30 3a 30
| 
| and 0x3038 equals 12344 decimal, so something's wrong at creating the image file
| I couldn't yet figure out why this is so.
| Can someone confirm this behavoiur? 

I applied the patch, but I don't have a clue about the other problem.

On my system, graphics magick appears to be compiled with 
--quantum-depth=8, as writing 16-bit images doesn't seem to work.
For compatibility with Matlab, do we need to have it compiled with
--quantum-depth=16?

jwe