search

JuliaImages / ImageTransformations.jl

Geometric transformations on images for Julia
Other
46 stars 27 forks source link

Relationship to AffineTransforms #2

Closed Evizero closed 7 years ago

Evizero commented 7 years ago

If I understand it right, then this package would have a lot of overlap with https://github.com/timholy/AffineTransforms.jl.

Am I correct to assume that this package is planned to be a reboot of sorts, making use of 0.5 goodies and specialized backends such as CoordinateTransformations?

timholy commented 7 years ago

Yes to both. Not there yet.

A future imresize should also live here.

Evizero commented 7 years ago

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.

mronian commented 7 years ago

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

Evizero commented 7 years ago

naively I would guess CameraGeometry builds on ImageTransformations

timholy commented 7 years ago

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 :sweat_smile:.

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?

Evizero commented 7 years ago

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

mronian commented 7 years ago

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 :thinking: (with separate packages)

andyferris commented 7 years ago

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.

c42f commented 7 years ago

@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 https://github.com/FugroRoames/CoordinateTransformations.jl/pull/20

c42f commented 7 years ago

@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 :-)

andyferris commented 7 years ago

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

andyferris commented 7 years ago

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.

c42f commented 7 years ago

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.

mronian commented 7 years ago

@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 :smile: Maybe we should first decide some sort of roadmap and how things would work?

c42f commented 7 years ago

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