bugGNU Octave - Bugs: bug #44794, image package: imtransform should...


bug #44794: image package: imtransform should use 0 instead of NaN for the default extrapolation value

Submitter:  Hartmut <hardy>
Submitted:  Thu 09 Apr 2015 06:33:09 PM UTC
Category:  Octave Forge Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 3.8.2 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Wed 15 Apr 2015 03:58:31 PM UTC, comment #12: 

Thank you for the patch.

I pushed this changes after a small changes


I rebased it to the current default (the @ bookmark had been left behind), and I added a NEWS note to the commit.

Carnë Draug <carandraug>
Group Member
Wed 15 Apr 2015 12:37:32 PM UTC, comment #11: 

As H.G. noted, Octave's output is not quite right in the sense that it returns 4 columns instead of 3 when using "xdata = [1 3]". On the other hand, when (if) this issue is fixed, the test will still be valid anyway. So I'd vote to push it as is.

Something else that I think is worth noting in Matlab output (for bug #44830): using the identity matrix for the transform I expect the same value for valid output pixels as input pixels, i.e. ones. Even if we are doing something wrong with xdata, I'd expect at least the output to be the same for both rows! Are they using some dithering (error propagation algorithm) that dissymmetries the output? I'm really puzzled.

Pantxo Diribarne <pantxo>
Group Member
Wed 15 Apr 2015 10:14:26 AM UTC, comment #10: 

The test fails in Matlab (R2010b)

>> im = rand (2);
>> tmat = [eye(2); 0 0];
>> T = maketform ('affine', tmat);
>> im2 = imtransform (im, T, 'xdata', [1 3]);
??? Error using ==> imtransform>parse_inputs at 454
If either 'XData' or 'YData' is specified, then both must be specified.

Error in ==> imtransform at 264
args = parse_inputs(varargin{:});

but If I set Ydata, then:

>> im2 = imtransform (im, T, 'xdata', [1 3], 'ydata', [1 3])

im2 =

    0.8147    0.1270         0
    0.9058    0.9134         0
         0         0         0

>> im2 = imtransform (im, T, 'xdata', [1 3], 'ydata', [1 2])

im2 =

    0.8147    0.1270         0
    0.9058    0.9134         0

This sounds about right to me but you're more familiar with this function.

Carnë Draug <carandraug>
Group Member
Tue 14 Apr 2015 08:43:21 PM UTC, comment #9: 

@H.G.: because of the way I understood ML doc :-): xdata = [1 3] doesn't mean there will be 3 pixels, it means "the coordinate of the last column in the output space will be 3". In that case the output scale is taken equal to the input scale which in turn is computed (here may be the mistake) using

I was also surprised and about to ask for a test: what does Matlab return for this test?

Pantxo Diribarne <pantxo>
Group Member
Tue 14 Apr 2015 06:46:04 PM UTC, comment #8: 

Thanks. This test looks fine for me to test for the expected behavior.

@Pantxo: By the way, why does im2 in your test have 4 columns? Shouldn't it only have 3 columns, as specified by your xdata = [1,3] ? Is this another bug, or am I just misled about the intended functionality of the xdata option?

Hartmut <hardy>
Tue 14 Apr 2015 05:01:35 PM UTC, comment #7: 

I attached a new patch with a test.

(file #33673)

Pantxo Diribarne <pantxo>
Group Member
Tue 14 Apr 2015 12:26:41 PM UTC, comment #6: 

Could you please also add a test to the cset?

Carnë Draug <carandraug>
Group Member
Tue 14 Apr 2015 09:20:19 AM UTC, comment #5: 

Thanks for supplying a patch for this, Pantxo! It fixes the fill values and makes the Octave function in this respect Matlab compatible. Could someone upload this into the image package repository?

I will file another bug report (in the next days) for the different numbers that the Octave version of imtransform produces, compared to the Matlab version.

Hartmut <hardy>
Mon 13 Apr 2015 08:02:24 PM UTC, comment #4: 

I attached a patch.

@H.G.: you mentioned Octave not returning the same values as Matlab. Can you file another bug report about this?

(file #33667)

Pantxo Diribarne <pantxo>
Group Member
Fri 10 Apr 2015 10:43:57 AM UTC, comment #3: 

The process of transforming the image is as follows:

  • Define a transform: in this example it is defined by the user who provides a direct transform (here a pure rotation matrix).
  • infer the reverse transform.
  • infer the size of the output image using the direct transform: here rotating the image by 45deg makes the output image necessarily larger than the input one (widthout = ceil (witdthin * sqrt (2))).
  • For each pixel in the output space, use the reverse transform to infer the corresponding coordinates in the input space.
  • use interp2 in the input space to find the  interpolated value of the pixel in the output space.

When a pixel in the output space is not defined in the input space, its value (gray level here) will be replaced by a fixed EXTRAP value (see "help interp2"). Solving this bug is just a matter of changing the default value of the "fillvalue" property in imtransform.m.

Pantxo Diribarne <pantxo>
Group Member
Thu 09 Apr 2015 07:57:20 PM UTC, comment #2: 

Daniel wrote (somehow privatly through savannah, I don't know how):
M = [0 1 0; 0 1 0; 0 1 0];
t = maketform('affine',[cosd(a) sind(a) 0; -sind(a) cosd(a) 0;0 0 1]);

With this I got the same result, with image2.4
Can anyone educate me where to start if I want to fix this bug?

@Carne: Could you give Daniel a hint where to start with this?

Hartmut <hardy>
Thu 09 Apr 2015 07:10:32 PM UTC, comment #1: 

Such backwards incompatible won't make it until release 2.6.0. But can you provide a changeset for the change?

Carnë Draug <carandraug>
Group Member
Thu 09 Apr 2015 06:33:09 PM UTC, original submission:  

Here is a little script to show the behavior:

M = [0 1 0; 0 1 0; 0 1 0];
t = maketform('affine',[cosd(a) sind(a) 0; -sind(a) cosd(a) 0; 0 1]);
imtrans = imtransform(M,t)

If you run this with the image package (m-files from image-2.4.0 under Octave 3.8.2), then you get this result:

imtrans =

       NaN       NaN       NaN       NaN
       NaN   0.33333   1.00000       NaN
       NaN   1.00000   0.33333       NaN
       NaN       NaN       NaN       NaN

With Matlab you get (slightly different numbers, but that's not the point of this bug report, and) padded outside with 0 values instead of the NaN values of Octave.

I think this was fixed for the imrotate, imremap, and imperspectivewarp functions with the image-2.4.0 release. But it seems to me that it's not fixed for the imtransform function yet.

Hartmut <hardy>


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

Attach Files:

Attached Files
file #33673:  fix_fillvalues2.patch added by pantxo (2KiB - text/x-diff)
file #33667:  fix_fillvalues.patch added by pantxo (710B - text/x-diff)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by hardy
  • -email is unavailable- added by hardy (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 project members can vote.


    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-04-15 carandraug StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2015-04-14 pantxo Attached File- Added fix_fillvalues2.patch, #33673
    2015-04-13 pantxo Attached File- Added fix_fillvalues.patch, #33667
    2015-04-10 pantxo StatusNone Confirmed
    2015-04-09 hardy Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.12.
    Corresponding source code