Wed 21 Mar 2012 05:44:26 AM UTC, comment #22:
I am also having the problem running Octave 3.2.4 on Windows
|
Mon 30 Jan 2012 07:54:18 PM UTC, comment #21:
It should not be present on any octave 3.4.x with
GraphicsMagick-1.3.13 (released 24th Dec 2011).
|
Sun 29 Jan 2012 12:14:39 AM UTC, comment #20:
Is this problem still present in 3.6.0?
|
Tue 29 Jun 2010 07:29:48 AM UTC, comment #19:
attached the patches used to port
octave-3.2.4 and graphicsmagick-1.3.12
at the same time on cygwin.
for GraphicsMagick the changes at
GraphicsMagick-1.3.12/magick/command.c
GraphicsMagick-1.3.12/magick/magick.c
solve the semaphore problem; the rest is cygwin specific.
for Octave the change at
octave-3.2.4/src/DLD-FUNCTIONS/__magick_read__.cc
is a backport from octave 3.3.51+ and solves the GraphicsMagick
inizialization; the rest is cygwin specific.
Regards
Marco
(file #20849, file #20850)
|
Mon 28 Jun 2010 07:26:57 PM UTC, comment #18:
On Fedora 13, imread causing problems .
|
Sat 05 Jun 2010 11:08:54 PM UTC, comment #17:
On Fedora 13, I found that upon any imread invocation, GraphicsMagick-1.3.12 hit the semaphore bug shown below and caused an octave-core dump. octave-3.2.3 and GraphicsMagick-1.3.7 work together on both Fedora 13 and Fedora 12. As far as I can tell, octave-3.2.4 and GraphicsMagick-1.3.12 are unusable together. octave-3.2.4 also does not work with GraphicsMagick-1.3.7 on Fedora 12.
Summary: I recommend Fedora 12 and 13 users to version-pin on octave-3.2.3 and GraphicsMagick-1.3.7.
I'd be happy to send more diagnostics if anyone wants them, but the problem is 100% reproducible.
|
Sat 05 Jun 2010 01:40:42 AM UTC, comment #16:
I have the same problem as Hans-Jurgen on Fedora 12 and Fedora 13 using octave-3.2.4 and image-1.0.13. octave-3.2.3 works fine with image-1.0.13. Perhaps we need to use a different version of GraphicsMagick? If I find the answer, I will post here again.
|
Thu 03 Jun 2010 07:53:44 PM UTC, comment #15:
on mac os 10.6.3 with octave 3.2.4 (64 bit) I have to use imread:
octave:4> A = imread("Gears2.tiff")
Assertion failed: (semaphore_info != (SemaphoreInfo *) NULL), function LockSemaphoreInfo, file magick/semaphore.c, line 525.
panic: Abort trap -- stopping myself...
Abort trap
This crash happens on every image format.
Does anybody have a hint?
I cannot use octave anymore, because I work with images.
Cheers,
grepi
|
Mon 10 May 2010 11:35:26 PM UTC, comment #14:
I can confirm this behavior on two different Windows machines (XP) running 3.2.4; works properly in 3.2.2.
IMAGE_PATH = ".;c:/foo" yet
the path that is passed to file_in_path.m from imread.m is the default ".;Octave\3.2.4_gcc-4.4.0\share\octave\3.2.4\imagelib"
If I use file_in_path(IMAGE_PATH, "image.tif"); it correctly finds it. If I call the same command from imread("image.tif") it does not as it searches the wrong directory.
I know this sounds really weird, but I confirmed this by adding a line to file_in_path to print the passed path parameter.
|
Thu 08 Apr 2010 08:53:36 PM UTC, comment #13:
The work around work so the problem seems limited to the file_in_path routine.
Now I am back to why imwrite (actually _magick_write_ )doesn't output correctly for the Windows platform. Should I report that to the GraphicsMagick developers directly?
|
Thu 08 Apr 2010 08:42:14 PM UTC, comment #12:
Looking at the diffs between 3.2.3 and 3.2.4, I don't see any reason that accounts for this difference.
Can anyone else confirm this behavior with the Windows binary?
Since I'm unable to reproduce this problem and I don't use Windows (or have access to a Windows system suitable for debugging) someone else will have to debug this problem.
As a workaround, I think you should be able to modify the imread function to do
fn = filename
instead of
fn = file_in_path (IMAGE_PATH, filename);
Then it won't search IMAGE_PATH for the image file, but at least it should be able to open the file if it can be found relative to the current directory or if it is specified with an absolute filename.
|
Thu 08 Apr 2010 08:15:04 PM UTC, comment #11:
That is interesting in 3.2.3 you get the correct output.
> file_in_path('.', 'pickoutcentralin.png')
ans = c:\rotationtests\pickoutcentralin.png
octave-3.2.3.exe:5:c:\rotationtests
>
but in 3.2.4 the output is not correct.
> file_in_path('.', 'pickoutceantralin.png')
ans = [](0x0)
octave-3.2.4.exe:7>
|
Thu 08 Apr 2010 07:36:23 PM UTC, comment #10:
OK, when you are in the C:\Rotationtests directory, what happens if you do
file_in_path (IMAGE_PATH, 'pickoutcentralin.png')
and
file_in_path ('.', 'pickoutcentralin.png')
at the Octave prompt?
|
Thu 08 Apr 2010 07:29:19 PM UTC, comment #9:
I appreciate the scepticism as I would approach this in the same way given someone with my lack of experience <grin>
I am in the correct directory. Here is the output of the commands
octave-3.2.4.exe:2> pwd
ans = C:\Rotationtests
octave-3.2.4.exe:3> x=dir('pickoutcentralin.png')
x =
{
name = pickoutcentralin.png
date = 08-Apr-2010 08:48:58
bytes = 25183
isdir = 0
datenum = 7.3421e+005
statinfo =
{
dev = 2
ino = 0
mode = 33206
modestr = -rw-rw-rw-
nlink = 1
uid = 0
gid = 0
rdev = 2
size = 25183
atime = 1.2708e+009
mtime = 1.2707e+009
ctime = 1.2707e+009
}
}
IMAGE_PATH is defined as
octave-3.2.4.exe:4> IMAGE_PATH()
ans = .;C:\Octave\3.2.4_gcc-4.4.0\share\octave\3.2.4\imagelib
which is simialr to that defined in version 3.2.3.
|
Thu 08 Apr 2010 07:21:40 PM UTC, comment #8:
Also, what is the value of IMAGE_PATH when you run Octave?
|
Thu 08 Apr 2010 07:20:10 PM UTC, comment #7:
Are you sure you are changing to the correct directory?
After the cd command, what happens if you do
pwd
x = dir ('pickoutcentralin.png')
?
|
Thu 08 Apr 2010 07:15:28 PM UTC, comment #6:
Unfortuntately no. I originally started off with what you suggested and added the path to see if it made a difference.
octave-3.2.4.exe:2> run imwritetest.m;
imread: cannot find pickoutcentralin.png
error: called from `imread' in file C:\Octave\3.2.4_gcc-4.4.0\share\octave\3.2.4\m\image\imread.m near line 53, column 5
error: called from:
error: C:\Octave\3.2.4_gcc-4.4.0\share\octave\3.2.4\m\miscellaneous\run.m at line 53, column 7
octave-3.2.4.exe:2>
|
Thu 08 Apr 2010 07:08:13 PM UTC, comment #5:
Does it work if you do
cd C:/Rotationtests;
I = imread('pickoutcentralin.png');
imwrite(I,'pickoutcentralout.png');
instead?
|
Thu 08 Apr 2010 06:46:00 PM UTC, comment #4:
Turns out both 3.2.3 and 3.2.4 are using the same version of GraphicsMagick 1.3.7
|
Thu 08 Apr 2010 06:41:02 PM UTC, comment #3:
Here is the actual error message. Octave failes to read the file I specified even though it works in 3.2.3
I am using the version of Octave downloaded from Octave Forge at http://octave.sourceforge.net/
When I step into the imread.m file, it seems like
the problem is in the function
fn = file_in_path (IMAGE_PATH, filename);
which returns empty in the next block.
if (isempty (fn))
error ("imread: cannot find %s", filename);
endif
octave-3.2.4.exe:2> run imwritetest.m;
imread: cannot find c:\rotationtests\pickoutcentralin.png
error: called from `imread' in file C:\Octave\3.2.4_gcc-4.4.0\share\octave\3.2.4\m\image\imread.m near line 53, column 5
error: called from:
error: C:\Octave\3.2.4_gcc-4.4.0\share\octave\3.2.4\m\miscellaneous\run.m at line 53, column 7
octave-3.2.4.exe:2>
|
Thu 08 Apr 2010 04:17:52 PM UTC, comment #2:
Precisely how does imread fail for you?
It seems to work correctly for me with Octave 3.2.4 and the current development sources on a Debian system. It looks like I have GraphicsMagick 1.3.5 installed (Debian package).
|
Thu 08 Apr 2010 04:10:52 PM UTC, comment #1:
octave 3.2.4 for cygwin with 1.3.7 GraphicsMagick
work fines.
Is it eventually a GM version (> 1.3.7) issue specific of mingw ?
Marco
|
Thu 08 Apr 2010 03:42:01 PM UTC, original submission:
In an attempt to move past the bug in the imwrite function that doesn't write out exactly what is sent in, I decided to try installing version 3.2.4.
Unfortuantley now, the imread function will not read the tiff file I am using as a test. I also did not work for the png format.
The sample code is exactly the same as that for the imwrite bug reported earlier.
|