The reference frame associated to an image is not the best one to perform a shear transformation about imagetransformations.jl HOT 6 OPEN

from imagetransformations.jl.

Thank you, I can work very well with ImageTransformation.jl and except the shear transformation I haven't encountered any problem. I managed very quickly to define structures for transforming an image by a complex function, in order to highlight the properties of functions defined on a disk or a rectangle in the complex plane, then transforming an image into a triangular one, polar transformations, and more.

from imagetransformations.jl.

A good catch. This might be due to the inconsistency of the axis order. In JuliaImages, we take the following order convention(x as the first axis, y as the second axis), so vertical_shear is indeed an horizontal_shear.

I think this is mostly a documentation issue and should be explained somewhere here or in the main JuliaImages documentation. See also JuliaImages/juliaimages.github.io#173

from imagetransformations.jl.

I'm wondering why you made this choice for the image coordinate system. I've worked with images in C/C++, Java, Python, Matlab and all of them consider the image coordinate system as in my last figure posted above.
Also Makie displays the images upside down, most likely due to an improper choice of the reference frame

from imagetransformations.jl.

I'm wondering why you made this choice for the image coordinate system.

I'm not the first one to introduce this notation, but I'll try to explain.
This is perhaps due to the fact that JuliaImages tries to make things dimensionality-agnostic -- many algorithms intrinsically support n-dimensional input. And if we take this into consideration, we typically call the axes "the first dimension", the second dimension", and "the i-th dimension". Furthermore, it's itself consistent to name the first dimension as the "x-axis", the second dimension as the "y-axis", the third "z-axis". In this sense, the x/y/z-notation is for computation in contrast to the commonly used camera coordinate system as you expected.

Also Makie displays the images upside down, most likely due to an improper choice of the reference frame

I believe all Julia image IO backends does this axis re-order, for instance, PNGFiles, JpegTurbo.jl so image(testimage("cameraman")) gives some strange display..

I'm not sure if it's a good idea to enforce the camera coordinate system into JuliaImages -- it's perhaps too late to do this kind of breaking change. Maybe we'll just need to document these two types of coordinates: one for computation, and one for visualization/camera.

also ping @timholy @zygmuntszpak for some inputs

from imagetransformations.jl.

I've worked with images in C/C++, Java, Python, Matlab and all of them consider the image coordinate system as in my last figure posted above.

We use a similar convention as Matlab. It comes from the fact that (1) both Matlab & Julia store matrices in column-fastest ("column-major") order, and that (2) for a matrix, in A[i, j] i means row (the vertical coordinate) and j means column (the horizontal coordinate). Hence we display images in a graphical window in the same way they show in the REPL.

The origin of the failure is, I believe, linear algebra notation dating back a few hundred years, which introduced a conflict between Cartesian ordering and matrix representations. So definitely send them a bug report 😉 .

from imagetransformations.jl.