Relationship to AffineTransforms about imagetransformations.jl HOT 15 CLOSED

@mronian I'd encourage you to consider making your transformations compatible with CoordinateTransformations.Transformation. Our intention with CoordinateTransformations is to first, have generic and efficient transformation composition and inverse, second, to allow transformations to be efficiently differentiated with respect to their input or parameters, to allow the use in optimization procedures. For cameras this should be particularly relevant if you're doing bundle adjustment, lens calibration, etc for 3D reconstruction like your package seems to be aiming at.

The PR @andyferris is referring to is JuliaGeometry/CoordinateTransformations.jl#20

from imagetransformations.jl.

Yes to both. Not there yet.

A future imresize should also live here.

from imagetransformations.jl.

Understood! I presume imresize is also intended to return a view (given the general theme of images nowadays).

I hope I will be able to help out here a lot. I certainly plan to, but I have proven myself wrong on such promises in the past.

from imagetransformations.jl.

I guess this overlaps with JuliaImages/CameraGeometry.jl too?

from imagetransformations.jl.

naively I would guess CameraGeometry builds on ImageTransformations

from imagetransformations.jl.

Understood! I presume imresize is also intended to return a view (given the general theme of images nowadays).

Actually, no: generic resizing can't be done efficiently as a view, I think.

I guess this overlaps with JuliaImages/CameraGeometry.jl too?

Oh gosh, I didn't even think of that. Sorry about that. But oh, wait, there's no code there yet, so no duplicated effort I hope 😅.

Yes, if that's the mission of CameraGeometry, we should centralize them somehow. I'm fine with moving this code to CameraGeometry, although I wonder if ImageTransformations is a better name?

from imagetransformations.jl.

Are they the same thing though? I would have guessed, half informed as I am, that CameraGeometry focuses more on algorithms that derive the appropriate set transformations (and their parameters) to use in specific situations, while ImageTransformations provides many of the transformations themselves

from imagetransformations.jl.

CameraGeometry focuses more on algorithms that derive the appropriate set transformations (and their parameters) to use in specific situations, while ImageTransformations provides many of the transformations themselves

I guess the current structure is fine then 🤔 (with separate packages)

from imagetransformations.jl.

In CoordinateTransformations.jl we are just adding now a PerspectiveMap transformation to handle cameras (one can position a camera with exisiting transformations and chain these together). In ImageTransformations.jl we should have enough support for warps and lens corrections and so on (which again can be chained). I was hoping that between the two there should be solid support for cameras, but I'm also happy to factor things out differently if that is better.

Also 3D reconstruction is an interesting one! One might consider a Ray type to help with the (psuedo) inverse of PerspectiveMap or something. I'm not sure where that should live.

from imagetransformations.jl.

@andyferris a Ray type is quite a generic concept, as the set of rays is isomorphic to the tangent bundle of the 3D space. I feel like standard objects from differential geometry are a good fit for CoordinateTransformations... I guess the trick is to make the generic differential geometry concepts practical and approachable :-)

from imagetransformations.jl.

@c42f right, true, especially the "practical and approachable" part

from imagetransformations.jl.

To follow up, I was hoping Ray was more approachable than TangentBundle but maybe that's just because I haven't studied many differential geometry/geometric algebra concepts.

from imagetransformations.jl.

Definitely! That's my point really: I think generic differential geometry concepts are fair game for CoordinateTransformations (provided they're practically useful in numerical code) , but we should use friendly names where possible.

from imagetransformations.jl.

@c42f , @andyferris I love the way CoordinateTransformations.jl works and would enjoy working with you to develop CameraGeometry.jl. I will be working on this during my winter break (December) and definitely need help 😄 Maybe we should first decide some sort of roadmap and how things would work?

from imagetransformations.jl.

Great! I think we can continue this discussion over at CameraGeometry.

from imagetransformations.jl.