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

 
 

bug #57504: [octave forge] (image) Scaling error for imresize in Image 2.0.0

Submitter:  None
Submitted:  Mon 30 Dec 2019 01:49:04 PM UTC
   
 
Category:  Octave Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Duplicate Assigned to:  None
Originator Name:  Pawel M Stasik Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * other
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 02 Apr 2021 03:36:34 PM UTC, comment #8: 

Closed as duplicate of bug #51769

Avinoam Kalma <avinoam>
Group Member
Wed 10 Feb 2021 08:49:04 AM UTC, comment #7: 

comment #5:

> Isn't this the same as bug #51769?


I agree and think there is no further explanation required. I described the issue in bug #51769 in more detail.

This bug can be closed as duplicate, I guess.

Christof Kaufmann <christofkaufmann>
Sun 26 Jul 2020 08:49:26 PM UTC, comment #6: 

ping: to OP: see comment #4

Avinoam Kalma <avinoam>
Group Member
Thu 30 Jan 2020 09:09:15 AM UTC, comment #5: 

Isn't this the same as bug #51769?

Anonymous
Tue 31 Dec 2019 08:34:36 PM UTC, comment #4: 

Thanks for your detailed explanation, but could you please
attach an image that imresize works bad, and send also the correct
image.
Thanks

Avinoam Kalma <avinoam>
Group Member
Tue 31 Dec 2019 02:46:16 PM UTC, comment #3: 

comment #2:

> To OP:
> Thanks for reporting.
> Image package last version is 2.10.0.
> Could you please add an example that shows that imresize has a problem in this version?
>


Of course. In version 2.10 of Image in the lines 134-135 there is:

> [XI, YI] = meshgrid (linspace (1, inCols, outCols), linspace (1, inRows, outRows));
> im = imremap (im, XI, YI, method);


which is exactly what I mentioned (the indexes of pixels are computed using linspace from 1 to the final index.

I have not made checks in regards to clever indexing implemented for the case of the nearest neighbour. for for each other method the lines I provided above are used. The simplest explanation why this approach is wrong can be seen in two things. First the pixels are supposed to be points of reference in their centres. Second, the pixels represent an area; in a system that starts indexing from 0, an image that's N-pixels wide would have coordinate 0 represented as the left border of the first pixel and the coordinate N as the right border of the last pixel (in case of systems indexing from 1 like Octave, the right edge represents N+1).

OP

Anonymous
Mon 30 Dec 2019 09:18:31 PM UTC, comment #2: 

To OP:
Thanks for reporting.
Image package last version is 2.10.0.
Could you please add an example that shows that imresize has a problem in this version?

Avinoam Kalma <avinoam>
Group Member
Mon 30 Dec 2019 08:49:01 PM UTC, comment #1: 

Add people to CC

Avinoam Kalma <avinoam>
Group Member
Mon 30 Dec 2019 01:49:04 PM UTC, original submission:  

I've noticed this bug some time ago.

When the function scales the image, it uses the indexes of the pixels as the coordinates. This is wrong, as the actual approach should be assuming the points of interest should be in the middle of pixels - so shifted by 0.5. The way the interpolation is implemented in Image 2.0.0 results in a small zoom. I've checked the newest release of the image package (2.6.0) and it seems the error is still in there.

I use the following procedure to resolve the issue for myself (at the basis).

***

XI = 1:targetWidth;
XI = size(im,2)/targetWidth*(XI-0.5)+0.5;

YI = 1:targetHeight;
YI = size(im,1)/targetHeight*(YI-0.5)+0.5;

im_scaled = imremap(im, XI, YI);

***
I can't recall it now perfectly, but I might have included some code to ensure the indexes don't exceed the image. So it's worth taking into account that border-cases also might need being taken care of. As I've said, I don't recall perfectly now id imremap requires that.

I have not updated my Octave in some time, but I reckon unless the Image package was updated, the error is still in it.

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 christofkaufmann (Posted a comment)
  • -email is unavailable- added by avinoam (Posted a comment)
  • -email is unavailable- added by avinoam
  • -email is unavailable- added by avinoam
  • -email is unavailable- added by None (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
    2021-04-02 avinoam StatusNone Duplicate
        Open/ClosedOpen Closed
        Release5.1.0 other
    2019-12-30 avinoam SummaryScaling error for imresize in Image 2.0.0 [octave forge] (image) Scaling error for imresize in Image 2.0.0
    2019-12-30 avinoam Carbon-Copy- Added carandraug
        Carbon-Copy- Added hardy
    2019-12-30 rik5 Carbon-CopyRemoved 72865 -
    2019-12-30 rik5 CategoryOctave Function Octave Package

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code