[Octave-bug-tracker] [bug #43495] Crash when reading large TIFF with imread()

[Rik]

Follow-up Comment #11, bug #43495 (project octave):

@Arun: Try the large index version of Octave and report back if it makes a
difference.

The problem from Octave's perspective is that we do not know the return size
of the image ahead of time.  The whole point of using the external
GraphicsMagick package is to take care of all the annoying image formats. 
Sometimes, for example, an RGB JPEG image will be returned as a grayscale
image (1/3 the memory) if the R, G, and B planes all have the same value.

So, my guess is that GraphicsMagick itself is trying to load the file, and
choosing a format that is too large initially, which leads to a segfault.  On
a successful load the end class is logical, or just 1B per pixel, but it may
be loading it at TrueColor depth of 4B per pixel first before slimming it
down.

As Armin tested, 


x = ones (15153, 20127, "logical")
WORKS, storage required is 15153*20127*1 = ~305 MB

x = ones (15153, 20127)
FAILS, storage required is 15153*20127*8 = 2.4 GB


This sure looks like an indication that it is exceeding a 32-bit range.  Note
that for int32 the top-bit is often used as a valid bit so the real range is
just to 2^31 which is 2.1GB.

I suppose a way to be certain is to try


x = ones (15153, 20127, "int32");


This would require only 1.2GB which should not cause any problems.


    _______________________________________________________

Reply to this item at:

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

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