bugGNU Octave - Bugs: bug #29474, imread will not read graphics files

 
 

bug #29474: imread will not read graphics files

Submitter:  Ian Journeaux <ijourneaux>
Submitted:  Thu 08 Apr 2010 03:42:01 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Ian Journeaux Open/Closed:  * Closed
Release:  * 3.2.4 Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 21 Mar 2012 05:44:26 AM UTC, comment #23: 

I am also having the problem running Octave 3.2.4 on Windows

kyle polich <kpolich>
Mon 30 Jan 2012 07:54:18 PM UTC, comment #22: 

It should not be present on any octave 3.4.x with
GraphicsMagick-1.3.13 (released 24th Dec 2011).

marco atzeri <matzeri>
Sun 29 Jan 2012 12:14:39 AM UTC, comment #21: 

Is this problem still present in 3.6.0?

Jordi Gutiérrez Hermoso <jordigh>
Group Member
  Spam posted by anonymous
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)

marco atzeri <matzeri>
Mon 28 Jun 2010 07:26:57 PM UTC, comment #18: 

On Fedora 13, imread causing problems .

Colm Sean Kennedy <colmkennedy123>
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.

Alison Chaiken <alison>
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.

Alison Chaiken <alison>
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

Hans-Jürgen Greif <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.

Tim Williams <timmyw>
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?

Ian Journeaux <ijourneaux>
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.

John W. Eaton <jwe>
Group administrator
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>

Ian Journeaux <ijourneaux>
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?

John W. Eaton <jwe>
Group administrator
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.

Ian Journeaux <ijourneaux>
Thu 08 Apr 2010 07:21:40 PM UTC, comment #8: 

Also, what is the value of IMAGE_PATH when you run Octave?

John W. Eaton <jwe>
Group administrator
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')

?

John W. Eaton <jwe>
Group administrator
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>

Ian Journeaux <ijourneaux>
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?

John W. Eaton <jwe>
Group administrator
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

Ian Journeaux <ijourneaux>
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>

Ian Journeaux <ijourneaux>
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).

John W. Eaton <jwe>
Group administrator
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

marco atzeri <matzeri>
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.

Ian Journeaux <ijourneaux>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #20849:  octave-3.2.4-3.src.patch added by matzeri (2KiB - text/x-diff)
file #20160:  imwritetest.m added by ijourneaux (130B - text/plain)
file #20161:  pickoutcentralin.png added by ijourneaux (25KiB - image/x-png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Updated the item)
  • -email is unavailable- added by kpolich (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by colmkennedy123 (Posted a comment)
  • -email is unavailable- added by alison (Posted a comment)
  • -email is unavailable- added by grepi (Posted a comment)
  • -email is unavailable- added by timmyw (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by matzeri (Posted a comment)
  • -email is unavailable- added by ijourneaux (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-08-21 rik5 StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2010-10-21 jwe StatusWorks For Me Patch Submitted
    2010-06-29 matzeri Attached File- Added octave-3.2.4-3.src.patch, #20849
        Attached File- Added GraphicsMagick-1.3.12-1.src.patch, #20850
    2010-04-08 jwe StatusNone Works For Me
    2010-04-08 ijourneaux Attached File- Added imwritetest.m, #20160
        Attached File- Added pickoutcentralin.png, #20161

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code