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

 
 

bug #60336: [octave forge] (image) imresize does not accept complex input values

Submitted by:  Hartmut <hardy>
Submitted on:  Sun 04 Apr 2021 03:55:30 PM UTC  
 
Category:  Octave Forge Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  None Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  other Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

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

 

Wed 07 Apr 2021 07:25:51 PM UTC, comment #2: 

Attached is a small patch (V1) that fixes this issue using my currently preferred way ("2." in comment #1).

Please review.

(file #51208)

Hartmut <hardy>
Sun 04 Apr 2021 04:56:58 PM UTC, comment #1: 

I have now even read in the Matlab documentation that the input image for imresize would need to be real. But this is not true, Matlab behaves differently, its documentation is just wrong in this point.

I see two ways to make our code more Matlab compatible in this issue, and I am unsure which one is best:

1. change our private function isimage.m by deleting its check for real-ness. Pro: imresize (and imremap) could then stay unchanged. And we would still use our helper function "isimage" as often as we use it now, this makes our code base more uniform and therefore maybe easier to maintain. Con: In all image functions that call isimage.m (how many are this?) we would then need to add a small check for real-ness next to the call to isimage. This makes many functions a bit more messy (and maybe harder to maintain).

2. change imresize.m (and unfortunatelly also our helper function imremap.m) such that it does the input checking itself and not uses isimage any more,  it would mostly check for the same just without the check for real-ness. Con: This would give us two ugly lines of code at the beginning of each imresize.m and umremap.m. And we would make use of our isimage helper function two times less. Pro: we do not need to touch all other image functions.

@Carne, @Avinoam: This seems to be a design decision to me. So please let me know what you think about this. (I am currently leaning a bit more to version 2...)

Hartmut <hardy>
Sun 04 Apr 2021 03:55:30 PM UTC, original submission:  

As mentioned in bug #60226, the Matlab version of imresize also accepts images with complex numbers as inputs. The current Octave version does not.

Here is a small example code that currently fails in Octave but works fine in Matlab:

in = ones(2) +1i
out = imresize(in, 1.5)

Matlab does not mention on its documentation page that it supports complex input values, but I have tested this with Online-Matlab and it really does. The Matlab result for the above code is identical to the output of "ones(3)+1i".

Hartmut <hardy>

 

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

Attach Files:
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by hardy
  • -email is unavailable- added by hardy
  • -email is unavailable- added by hardy (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-04-07 hardy Attached File- => Added imresize_complexinputs_V1.patch, #51208
    2021-04-04 hardy Carbon-Copy- => Added avinoam
        Carbon-Copy- => Added carandraug

    Back to the top


    Powered by Savane 3.6