Wed 15 Apr 2015 03:58:31 PM UTC, comment #12:
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.
|
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.
PS:
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.
|
Wed 15 Apr 2015 10:14:26 AM UTC, comment #10:
The test fails in Matlab (R2010b)
but If I set Ydata, then:
This sounds about right to me but you're more familiar with this function.
|
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
diff(udata)/columns(input_im)
I was also surprised and about to ask for a test: what does Matlab return for this test?
|
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?
|
Tue 14 Apr 2015 05:01:35 PM UTC, comment #7:
I attached a new patch with a test.
(file #33673)
|
Tue 14 Apr 2015 12:26:41 PM UTC, comment #6:
Could you please also add a test to the cset?
|
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.
|
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)
|
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.
|
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];
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?
|
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?
|
Thu 09 Apr 2015 06:33:09 PM UTC, original submission:
Here is a little script to show the behavior:
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:
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.
|