bugGNU Octave - Bugs: bug #41234, imread will not work with URLS


bug #41234: imread will not work with URLS

Submitted by:  John Donoghue <lostbard>
Submitted on:  Tue 14 Jan 2014 02:45:05 PM UTC  
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  John D Open/Closed:  Closed
Release:  3.8.0 Operating System:  Any

Add a New Comment (Rich Markup)

You are not logged in

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


( Jump to the original submission)

Fri 17 Jan 2014 11:43:00 PM UTC, comment #8: 

With cset 15db54c4a572 http://hg.savannah.gnu.org/hgweb/octave/rev/15db54c4a572

I added a few more tests to imread, imformats and imfinfo for the future.

This problem has been fixed in the development version. The fix
will be available in the next major software release. Thank you
for your bug report.

Carnë Draug <carandraug>
Project Member
Thu 16 Jan 2014 07:22:23 PM UTC, comment #7: 

Actually, the problem goes deeper than that. The function imread and imfinfo both use private/imageIO to find the format and call the correct one. My original understanding of matlab docuemntation when I did this last summer was that the function that do the actual reading would be given the original input, intact, that imread and imfinfo received. However, after some experimentation it seems I was wrong. Any format information is removed, and in the case of url, the function must receive the path for a local file, not a URL. This means that private/imageIO.m needs to be pretty much rewritten, and the handling of URLs done there.

I have fixed this with the attached changeset, but didn't push because it will cause failing tests in imformats (the tests are actually incorrect, they were based on my interpretation of how imformats should behave when users write their own reading functions which is pretty much undocumented). The tests are failing because the file MUST exist and the following function will now receive the absolute filepath.

Interestingly, it seems that Matlab does not clean after itself when files are a URL, and the reading fails.

(file #30292)

Carnë Draug <carandraug>
Project Member
Thu 16 Jan 2014 12:09:02 AM UTC, comment #6: 

Updated patch definitely made from the default  branch

(file #30285)

John Donoghue <lostbard>
Project Member
Wed 15 Jan 2014 08:44:56 PM UTC, comment #5: 

hmmm ... maybe?

It should only be:
add variable to track if need delete file, and protect:

# keep track of if need to delete a tmp file
delete_file = false;


Attempt to get the the file with urlwrite if couldnt find it locally (where it was reporting couldnt find the file).

[fn, status, msg] = urlwrite (filename, tmpnam ());
if (! status)
  error ("imread: cannot find or download %s", filename);
delete_file = true;

And the cleanup at the end of the function:
  if (delete_file)
    unlink (fn);

And some changes in the indenting because of the unwind_protect block.

In the version I was looking at, there wasnt any shared code for that section of the changes - but I did base my changes on what imfinfo was doing.

John Donoghue <lostbard>
Project Member
Wed 15 Jan 2014 08:32:23 PM UTC, comment #4: 

Also, since both imfinfo and imread are supposed to accept URL instead of file names, this should probably be fixed in some place where they use the same code. This should be easy because URLs are working fine in imfinfo.

Carnë Draug <carandraug>
Project Member
Wed 15 Jan 2014 08:24:15 PM UTC, comment #3: 

It seems to me that the diff undoes a bunch of other stuff done in the default version.

Was by any chance the original file picked from stable or gui-release, made some small changes, and applied to default?

Carnë Draug <carandraug>
Project Member
Wed 15 Jan 2014 07:17:39 PM UTC, comment #2: 

Should I push this, and if so, default, gui-release or stable?

John Donoghue <lostbard>
Project Member
Wed 15 Jan 2014 12:07:30 AM UTC, comment #1: 

Patch attached using pretty much the same code as imfinfo if it cant find a local file of the name.

(file #30276)

John Donoghue <lostbard>
Project Member
Tue 14 Jan 2014 02:45:05 PM UTC, original submission:  

According to 'doc imread', imread(URL) should work.
However it appears to only checks for a local file of that name, and if it doesn't exist, error.

Example run:

>> x = imread("http://www.gnu.org/software/octave/images/logo.png")
error: imread: cannot find http://www.gnu.org/software/octave/images/logo.png
error: called from:
error:   C:\Octave\Octave-3.8.0\share\octave\3.8.0\m\image\private\__imread__.m at line 56, column 5
error:   C:\Octave\Octave-3.8.0\share\octave\3.8.0\m\image\private\imageIO.m at line 66, column 26
error:   C:\Octave\Octave-3.8.0\share\octave\3.8.0\m\image\imread.m at line 107, column 30

imfinfo  works on urls.

John Donoghue <lostbard>
Project Member


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

Attach Files:

Attached Files
file #30292:  fix_imageIO.m added by carandraug (14KiB - text/x-objcsrc)
file #30285:  imread2.patch added by lostbard (9KiB - application/octet-stream - new patch)
file #30276:  imread-fix.patch added by lostbard (12KiB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by lostbard (Submitted the item)

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

    Only project members can vote.




    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-01-17 carandraug StatusPatch Submitted => Fixed
        Open/ClosedOpen => Closed
    2014-01-16 carandraug Attached File- => Added fix_imageIO.m, #30292
    2014-01-16 lostbard Attached File- => Added imread2.patch, #30285
    2014-01-15 lostbard Attached File- => Added imread-fix.patch, #30276
        StatusConfirmed => Patch Submitted
    2014-01-14 rik5 Carbon-CopyRemoved 72865 => -
    2014-01-14 rik5 StatusNone => Confirmed

    Back to the top

    Powered by Savane 3.5