Wed 04 Sep 2013 05:34:39 PM UTC, comment #23:
Well, I'll mark it as fixed then.
|
Wed 04 Sep 2013 11:44:47 AM UTC, 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.
|
Wed 04 Sep 2013 11:26:18 AM UTC, 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?)
|
Wed 04 Sep 2013 03:52:36 AM UTC, 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)
|
Wed 04 Sep 2013 01:02:13 AM UTC, comment #19:
I've attached the file. What is the default precision used by fwrite? Should it be int8?
(file #29000)
|
Wed 04 Sep 2013 12:03:08 AM UTC, 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:
|
Tue 03 Sep 2013 11:27:56 PM UTC, comment #17:
So, I should fread() an existing png and then attempt to use fwrite() to create a duplicate?
|
Tue 03 Sep 2013 11:05:58 PM UTC, 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?
|
Tue 03 Sep 2013 07:19:09 PM UTC, comment #15:
You mentioned fwrite(). Did you intend that I use imwrite()? I've attached the result of
(file #28998)
|
Tue 03 Sep 2013 05:53:34 PM UTC, comment #14:
I'm not familiar with the image stuff. What is the proper syntax to write the png file?
|
Tue 03 Sep 2013 02:47:41 PM UTC, 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.
|
Tue 03 Sep 2013 02:39:07 PM UTC, comment #12:
You are correct, I used imshow (). imread() does return the correct matrix.
|
Tue 03 Sep 2013 02:35:08 PM UTC, 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.
|
Tue 03 Sep 2013 02:24:41 PM UTC, comment #10:
I can read and display it without crashing, but the result isn't correct (see attached)
(file #28994)
|
Tue 03 Sep 2013 01:53:05 PM UTC, 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)
|
Tue 03 Sep 2013 12:37:58 PM UTC, comment #8:
Yes. I can read the example you liked to (with q8) and display it as well (see attached)
(file #28991)
|
Tue 03 Sep 2013 03:12:36 AM UTC, comment #7:
But does it fail with an actual png image file such as https://upload.wikimedia.org/wikipedia/en/7/70/Example.png ?
|
Mon 02 Sep 2013 04:59:22 PM UTC, comment #6:
Yes. It fails.
|
Mon 02 Sep 2013 02:21:00 PM UTC, 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.
|
Mon 02 Sep 2013 12:55:10 PM UTC, 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.
+verbatiim+
test imread
warning: your version of GraphicsMagick limits images to 8 bits per pixel
PASSES 1 out of 1 test
-verbatim+
|
Mon 02 Sep 2013 02:00:19 AM UTC, 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).
|
Sun 01 Sep 2013 09:03:36 PM UTC, comment #2:
The 32 bit variant also works "+q32"
|
Sun 01 Sep 2013 08:35:35 PM UTC, comment #1:
Carlo,
Are you using macports? If so, when I change the variant to +q16, "test imread" passes for me.
|
Mon 05 Aug 2013 10:38:37 AM UTC, original submission:
running in a debugger I get the following bactrace:
|