bugGNU Octave - Bugs: bug #54370, [octave forge] (image) imcrop...

 
 

bug #54370: [octave forge] (image) imcrop gives incorrect results in 2.8.0

Submitter:  None
Submitted:  Wed 25 Jul 2018 01:08:36 AM UTC
   
 
Category:  Octave Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * other
Operating System:  * Microsoft Windows Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 14 Aug 2018 02:20:26 AM UTC, comment #2: 

Thank you for the bug report and proposed fix.  I have committed it in
http://hg.code.sf.net/p/octave/image/rev/b56a9e8023e9 which will be part of the next patch release.

Carnë Draug <carandraug>
Group Member
Thu 26 Jul 2018 09:56:54 PM UTC, comment #1: 

boundary check is mixing up rows and columns:

line 180: i_end = min (..., size (cdata)(1:2))

this cannot be identified in a test with a square matrix

walterd <walterd>
Wed 25 Jul 2018 01:08:36 AM UTC, original submission:  

As a new feature imcrop should now adjust to the image boundaries. Unfortunately the cropping a) is incorrect even if 'rect' is fully within the image size, b) gives bad results if near the boundary, c) ends in an error where it should not. Examples 1-3, 4-5, 6 below, also comparison to v2.6.2 (as originally provided with Octave 4.4.0). The crop region is chosen to make the behaviour more visible. No picture comparison done, only size check of result.

original RGB image 4608x3584 width x height (landscape)

I = imread('P6302571sph.jpg');

1) imcrop(I , [3500 1600 1100 1980])
2) imcrop(I , [500 100 1100 1980])
3) imcrop(I , [1 1 1100 1980])
4) imcrop(I , [4600 3580 7 3])
5) imcrop(I , [4600 3580 8 4])
6) imcrop(I , [4600 3580 9 5])

v2.8.0 - dimension of cropped image
1) 1981x85x3 <= size incorrect
2) 1981x1101x3
3) 1981x1101x3
4) 4x0x3 <= bad
5) 5x0x3 <= bad
6) error: cdata(3585,_,_,_): but cdata has size 3584x4608x3 <= should not occur

v2.6.2 - all results as expected/defined
1) 1981x1101x3
2) 1981x1101x3
3) 1981x1101x3
4) 4x8x3
5) 5x9x3
6) error: cdata(3585,_,_,_): but cdata has size 3584x4608x3

System: fresh install of GNU Octave, version 4.4.0 on Windows 7 Home Premium. Octave was configured for "x86_64-w64-mingw32". Comes with pkg image 2.6.2. Upgrade to 2.8.0 with 'pkg install -forge image'.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by avinoam (Updated the item)
  • -email is unavailable- added by avinoam
  • -email is unavailable- added by avinoam
  •  

    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 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-08-14 carandraug StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2018-07-29 avinoam StatusNone Confirmed
        Release4.4.0 other
        Summaryimcrop gives incorrect results in 2.8.0 [octave forge] (image) imcrop gives incorrect results in 2.8.0
        Carbon-Copy- Added carandraug
        Carbon-Copy- Added hardy
    2018-07-26 walterd Carbon-CopyRemoved -email is unavailable- -
    2018-07-26 walterd Carbon-CopyRemoved 125383 -
    2018-07-25 walterd Carbon-Copy- Added -email is unavailable-
    2018-07-25 walterd Carbon-CopyRemoved walterd -
    2018-07-25 walterd Carbon-Copy- Added walterd

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code