Thank you for the patch.

I pushed this changes after a small changes

http://hg.code.sf.net/p/octave/image/rev/f4b9686301a9

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

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.

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?

Could you please also add a test to the cset?

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)

Daniel wrote (somehow privatly through savannah, I don't know how):
-----------
M = [0 1 0; 0 1 0; 0 1 0];
a=45;
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?

Here is a little script to show the behavior:

M = [0 1 0; 0 1 0; 0 1 0];
a=45;
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.