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

[Philip Nienhuis]

Update of bug #43495 (project octave):

             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #3:

I just tried to load the 6000 dpi variant in Octave-3.8.2 and Octave-3.9.0+
(both 64 bits w. 64-bit indexing) for Windows on a Core i5 laptop with 8 GB
RAM.
It took Octave 19 minutes to load the image, with Octave's RAM usage slowly
increasing from 2.5 to 4+ GB with a short initial peak of 5 GB. In the end,
Octave's RAM footprint was only 350 KB and "whos" says that img is 304984431
bytes (class logical).

As this works fine here but with quite a bit of RAM usage (>4 GB) I strongly
suspect that the Octave binary you used hasn't been built with --enable-64
flag, only with the --enable-windows-64 flag.
Try:
octave_config_info ("USE_64_BIT_IDX_T")
If the answer is "yes" Octave has been built with 64-bit indexing. If "no",
you're out of luck.

As to the time required to read the image, I can only guess that imread is
maybe not a very efficient routine for large files; >15 minutes just to
accommodate a bitmap (your TIFF has a bit depth of 1) looks excessive. Perhaps
Octave's imread (or rather the GraphicsMagic library) doesn't reserve the
required RAM in one time but extends RAM usage slice by slice until the entire
image has been processed (just my guess).

Closing report.

    _______________________________________________________

Reply to this item at:

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

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