Andy and Michael both commented on how GIL is complex and has lots of concepts. There is something rather easy that I can do to cut down on the concepts. GIL has abstract concepts for N-dimensional images/views/locators: PointNDConcept RandomAccessNDLocatorConcept MutableRandomAccessNDLocatorConcept RandomAccessNDImageViewConcept MutableRandomAccessNDImageViewConcept RandomAccessNDImageConcept Then it has refinements for them dealing with 2D: RandomAccess2DLocatorConcept MutableRandomAccess2DLocatorConcept RandomAccess2DImageViewConcept MutableRandomAccess2DImageViewConcept RandomAccess2DImageConcept Then it has further refinements dealing with pixel-based 2D images/views/locators: PixelLocatorConcept MutablePixelLocatorConcept ImageViewConcept MutableImageViewConcept ImageConcept Only the last ones have corresponding models. Although in theory one could represent things like video, 3D or lightfields as N-dimensional constructs, there are no existing models for them nor algorithms that take them. So one thought I have been toying with is removing the N-dimensional concepts until we end up needing them. Or maybe even removing the 2D concepts? That will cut down on the documentation with virtually no change in the code. Thoughts? Lubomir
Lubomir Bourdev wrote:
So one thought I have been toying with is removing the N-dimensional concepts until we end up needing them. Or maybe even removing the 2D concepts?
That will cut down on the documentation with virtually no change in the code. Thoughts?
What about volumetric data ? Wouldn't it make sense to allow for 3D grids / rasters ? (in VSIPL++ we deal with a Tensor type, but that's a little more general as the three dimensions don't need to be spatial dimensions...) I think it makes sense to leave the possibility open to provide optimized implementations for higher-dimensional pixel containers. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
"Lubomir Bourdev" <lbourdev@adobe.com> wrote in message news:B55F4112A7B48C44AF51E442990015C04C9940@namail1.corp.adobe.com...
Only the last ones have corresponding models. Although in theory one could represent things like video, 3D or lightfields as N-dimensional constructs, there are no existing models for them nor algorithms that take them.
So one thought I have been toying with is removing the N-dimensional concepts until we end up needing them. Or maybe even removing the 2D concepts?
That will cut down on the documentation with virtually no change in the code. Thoughts?
Well FWIW the transform code you showed looks quite interesting, but I would guess that you should use 4 x4 matrices. This would allow arbitrary 3D transformation of the Points in the Image (perspective, rotation round the x and y axes, assuming the image is in the xy plane), to interpolate them into 3D. regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message news:eg6fab$em6$1@sea.gmane.org...
"Lubomir Bourdev" <lbourdev@adobe.com> wrote in message news:B55F4112A7B48C44AF51E442990015C04C9940@namail1.corp.adobe.com...
Only the last ones have corresponding models. Although in theory one could represent things like video, 3D or lightfields as N-dimensional constructs, there are no existing models for them nor algorithms that take them.
So one thought I have been toying with is removing the N-dimensional concepts until we end up needing them. Or maybe even removing the 2D concepts?
That will cut down on the documentation with virtually no change in the code. Thoughts?
Well FWIW the transform code you showed looks quite interesting, but I would guess that you should use 4 x4 matrices. This would allow arbitrary 3D transformation of the Points in the Image (perspective, rotation round the x and y axes, assuming the image is in the xy plane), to interpolate them into 3D.
... and vice versa ;-) regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message
Well FWIW the transform code you showed looks quite interesting, but I would guess that you should use 4 x4 matrices. This would allow arbitrary 3D transformation of the Points in the Image (perspective, rotation round the x and y axes, assuming the image is in the xy plane), to interpolate them into 3D.
For the rest of Boosters: Andy refers to code in the numeric extension that you can download separately off GIL's web page. Note that the numeric extension is not part of the boost proposal. Andy, your comments seem unrelated to the thread I started... Lubomir
"Lubomir Bourdev" <lbourdev@adobe.com> wrote in message news:B55F4112A7B48C44AF51E442990015C04C9946@namail1.corp.adobe.com... "Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message
Well FWIW the transform code you showed looks quite interesting, but I would guess that you should use 4 x4 matrices. This would allow arbitrary 3D transformation of the Points in the Image (perspective, rotation round the x and y axes, assuming the image is in the xy plane), to interpolate them into 3D.
For the rest of Boosters: Andy refers to code in the numeric extension that you can download separately off GIL's web page. Note that the numeric extension is not part of the boost proposal. Andy, your comments seem unrelated to the thread I started... Well they arent. Separate the Concepts into more general ones and you will simplify the library and its concepts regards Andy Little
participants (3)
-
Andy Little -
Lubomir Bourdev -
Stefan Seefeld