bugGNU Octave - Bugs: bug #39698, imread test crashes Octave


bug #39698: imread test crashes Octave

Submitted by:  Carlo de Falco <cdf>
Submitted on:  Mon Aug 5 10:38:37 2013  
Category: Octave FunctionSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: FixedAssigned to: None
Originator Name: Open/Closed: Closed
Release: devOperating System: Mac OS

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Wed Sep 4 17:34:39 2013, comment #23:

Well, I'll mark it as fixed then.

Carnë Draug <carandraug>
Project Member
Wed Sep 4 11:44:47 2013, comment #22:

Hi I finally managed to build again with a new version of GraphicsMagick.

I am now using the latest version provided by MacPorts with the +q32 variant enabled and I also do not see the crash anymore.

I also seem to be able to load all the png's attached to this thread.

Carlo de Falco <cdf>
Project Member
Wed Sep 4 11:26:18 2013, comment #21:

I'm not sure the problem exists for me anymore. Could it just be that something on my end changed (i.e. macports updated something?)

Ben Abbott <bpabbott>
Project Member
Wed Sep 4 03:52:36 2013, comment #20:

Well, that's weird. Both imread and imfinfo work fine with that file on my computer. I don't know what to do next. Here's a resume for the future then:

  • this seems to occur in a Mac, with a file created in a Mac. A file created in Linux will not cause an error in a Mac, and a file created in a Mac will not cause an error in Linux.
  • only happens with imfinfo (imread works fine)
Carnë Draug <carandraug>
Project Member
Wed Sep 4 01:02:13 2013, comment #19:

I've attached the file. What is the default precision used by fwrite? Should it be int8?

(file #29000)

Ben Abbott <bpabbott>
Project Member
Wed Sep 4 00:03:08 2013, comment #18:

No. I'm sorry for the confusion.

I want to say to use the fwrite test on the example, and send me the png that your system generates. I'll then try to see if imfinfo fails on my side, trying to read the file you write. Basically, send me the file that the following snippet generates:

Carnë Draug <carandraug>
Project Member
Tue Sep 3 23:27:56 2013, comment #17:

So, I should fread() an existing png and then attempt to use fwrite() to create a duplicate?

Ben Abbott <bpabbott>
Project Member
Tue Sep 3 23:05:58 2013, comment #16:

No. I really meant fwrite(). The correct syntax to write an image file is indeed to use imwrite(). But the failing test uses fwrite(). My guess is that this is to avoid possible bugs in imwrite interfering with the test in imread. I don't know how it was done, possibly by creating the png file the correct way, and then using fread() to get a vector of doubles that could replicate it. You will notice that was written in the file has no obvious connection to the matrix that imread returns. Does that make sense to you?

Carnë Draug <carandraug>
Project Member
Tue Sep 3 19:19:09 2013, comment #15:

You mentioned fwrite(). Did you intend that I use imwrite()? I've attached the result of

(file #28998)

Ben Abbott <bpabbott>
Project Member
Tue Sep 3 17:53:34 2013, comment #14:

I'm not familiar with the image stuff. What is the proper syntax to write the png file?

Ben Abbott <bpabbott>
Project Member
Tue Sep 3 14:47:41 2013, comment #13:

Ok. So my theory is since fwrite() behaves differently in machines with different architectures, the test was writing different files. Could you send me the tmp.png that you system writes to test on mine? If this is indeed the cause of the problem, I'm guessing it can be fixed by specifying the architecture on fopen and fwrite.

Carnë Draug <carandraug>
Project Member
Tue Sep 3 14:39:07 2013, comment #12:

You are correct, I used imshow (). imread() does return the correct matrix.

Ben Abbott <bpabbott>
Project Member
Tue Sep 3 14:35:08 2013, comment #11:

That is the correct image if displayed with imshow. I get the same. Use image ou imagesc to get the matrix displayed. The important is that imread returns the following matrix from that png:

If imread returns that matrix then the problem lies somewhere on fwrite since that's the only thing that changed now.

Carnë Draug <carandraug>
Project Member
Tue Sep 3 14:24:41 2013, comment #10:

I can read and display it without crashing, but the result isn't correct (see attached)

(file #28994)

Ben Abbott <bpabbott>
Project Member
Tue Sep 3 13:53:05 2013, comment #9:

Then the problem was that imfinfo fails in Mac, when trying to read a file that is very weird to start with (the matrix that was written with fwrite is the one in the imread test).

imfinfo gets more than just height and width of the image. It tries to get a lot of metadata that simply does not exist in the file.

I don't know what we're doing wrong. Codewise everything looks correct to me and this only happens in Mac. The only thing that looks wrong is the actual "image" file. Can you try imfinfo with the one I attached? It's the same file, but written by my system.

(file #28993)

Carnë Draug <carandraug>
Project Member
Tue Sep 3 12:37:58 2013, comment #8:

Yes. I can read the example you liked to (with q8) and display it as well (see attached)

(file #28991)

Ben Abbott <bpabbott>
Project Member
Tue Sep 3 03:12:36 2013, comment #7:

But does it fail with an actual png image file such as https://upload.wikimedia.org/wikipedia/en/7/70/Example.png ?

Carnë Draug <carandraug>
Project Member
Mon Sep 2 16:59:22 2013, comment #6:

Yes. It fails.

Ben Abbott <bpabbott>
Project Member
Mon Sep 2 14:21:00 2013, comment #5:

That may be because I changed imread to no longer call imfinfo. Does the following fails?

If this fails but imfinfo with an actual png file passes, then the problem was in the actual test.

Carnë Draug <carandraug>
Project Member
Mon Sep 2 12:55:10 2013, comment #4:

I uninstalled GraphicsMagick+q8 and then reinstalled (i.e. new build and install). This time, there is no failure. I have no idea why.

test imread
warning: your version of GraphicsMagick limits images to 8 bits per pixel
PASSES 1 out of 1 test

Ben Abbott <bpabbott>
Project Member
Mon Sep 2 02:00:19 2013, comment #3:

If changing quantum depth fixes the problem is very weird if it's also true that the origin of the problem is in imfinfo.

Does imfinfo and imread using +q8 causes any trouble when using a real png file, or does it only fails with the png file on the imread test (which I'm unsure if it counts as a an actual png file).

Carnë Draug <carandraug>
Project Member
Sun Sep 1 21:03:36 2013, comment #2:

The 32 bit variant also works "+q32"

Ben Abbott <bpabbott>
Project Member
Sun Sep 1 20:35:35 2013, comment #1:


Are you using macports? If so, when I change the variant to +q16, "test imread" passes for me.

Ben Abbott <bpabbott>
Project Member
Mon Aug 5 10:38:37 2013, original submission:

running in a debugger I get the following bactrace:

Carlo de Falco <cdf>
Project Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):

Attached Files
file #29000:  send-this-file.png added by bpabbott (155B - image/png)
file #28998:  foo.png added by bpabbott (83B - image/png)
file #28994:  tmp-macosx.png added by bpabbott (40kB - image/png)
file #28993:  tmp.png added by carandraug (155B - image/png - file written during imread test in a x86_64 GNU/Linux system)
file #28991:  Example.png added by bpabbott (139kB - image/png)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by bpabbott (Posted a comment)
  • -unavailable- added by cdf (Submitted the item)
  • -unavailable- added by cdf

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed Sep 4 17:34:39 2013carandraugStatusNone=>Fixed
    Wed Sep 4 01:02:13 2013bpabbottAttached File-=>Added send-this-file.png, #29000
    Tue Sep 3 19:19:09 2013bpabbottAttached File-=>Added foo.png, #28998
    Tue Sep 3 14:24:41 2013bpabbottAttached File-=>Added tmp-macosx.png, #28994
    Tue Sep 3 13:53:05 2013carandraugAttached File-=>Added tmp.png, #28993
    Tue Sep 3 12:37:58 2013bpabbottAttached File-=>Added Example.png, #28991
    Mon Aug 5 10:38:37 2013cdfCarbon-Copy-=>Added carnë draug

    Back to the top

    Powered by Savane 3.1-cleanup