https://svn.lrde.epita.fr/svn/oln/trunk/milena
Index: ChangeLog
from Nicolas Ballas <ballas(a)lrde.epita.fr>
Continue documentation about image types and properties.
* sandbox/ballas/doc/image_tours.txt,
* sandbox/ballas/doc/draft.txt: update documentation.
draft.txt | 177 +++++++++++++++++++++++++++++++++++++++++++-------------
image_tours.txt | 13 +++-
2 files changed, 148 insertions(+), 42 deletions(-)
Index: sandbox/ballas/doc/image_tours.txt
--- sandbox/ballas/doc/image_tours.txt (revision 1857)
+++ sandbox/ballas/doc/image_tours.txt (working copy)
@@ -46,8 +46,8 @@
*** Static Checking
- Some operators are only define in special cases. Properties provide a way to
-check that the operator input type respect the operator requirement.
+ Some operators are only defined in special cases. Properties provide a way to
+check that the operator's input types respect the operator requirements.
*** Specialization of an Algorithm
(ex: dilatation/erosion).
@@ -60,6 +60,8 @@
depends on the property define in the property associated for the image
type. So, it is possible to recover some piece of interface depending on the
image type properties.
+
+//FIXME Bad example
For instance an Image2d has the bi-dimensional, and random value access.
properties. Hence, Image2d automatically provides a row/column access:
V at(Point2d<T>::coord x, Point2d<T>::coord y).
@@ -159,7 +161,7 @@
** Primitive Image
-Primitive image are image which are not based on another image type.
+Primitive image are images which are not based on another image type.
A primitive image type property can be either declared or automatically get
back with the help of associated types.
@@ -341,6 +343,7 @@
+
*** RLE Image
A RLE image can be defined as the following:
@@ -413,6 +416,8 @@
**** Connectivity based on a graph.
+** Image based on Lut
+
** Morpher (Derived Image)
Mopher are Image types which transform an Image type into a new type. So, they
@@ -425,6 +430,8 @@
*** Identity morpher
+ No change in the property.
+
*** Domain morpher
*** Value morpher
Index: sandbox/ballas/doc/draft.txt
--- sandbox/ballas/doc/draft.txt (revision 1857)
+++ sandbox/ballas/doc/draft.txt (working copy)
@@ -4,12 +4,20 @@
- nD image
-- Runs image (RLE/ Sparse/ value encoded...
+- Runs image (RLE/ Sparse/ value encoded...)
- Image based on a Lut (to define)
- graph image (see with Roland)
+- morpher
+
+- domain morpher
+
+- value morpher
+
+- identity morpher
+
* New redefinition of the image property
@@ -28,26 +36,22 @@
**** Definition
The size property give us an indication about the size (in memory) taken by
-the image. Indeed, an image can either huge or regular.
+the image. Indeed, an image can be either huge or regular.
"huge" means that the image cannot be fully store in the ram.
"regular" means that the image can be fully store in the ram.
**** Why does this property exist?
-As we can imagine, access to a "huge" image is way slower than accessing
-to "regular" image. Indeed, to access to "huge" image, we first need to load in
-the ram the interesting part of the image from the hard drive.
-
+As we can imagine, access to a "huge" image is slower than accessing
+to a "regular" image. Indeed, to access to "huge" image, we first need to
+load in the ram a part of the image, from the hard drive.
So, with this property, we can handle huge image in a different way in
the algorithms. (do inplace modification instead of create a new image for
instance, forbid the launch algorithm which create temporary image with huge
image...).
-
FIXME define large?
-
-
*** Border/Extended domain:
border: none,
@@ -55,9 +59,9 @@
FIXME: detail the problem, find example...
- The border property will probably change, because more information on
-the border.
-Actually a "border" is more extended domain of the image definition domain,
+ The border property will probably change, because we need more information
+about the image the borders.
+Actually a "border" is more an extended domain of the image definition domain,
than a simple border.
The idea is an algorithm should have the same behavior for the same image with
or without an extended domain.
@@ -65,7 +69,7 @@
problems:
If the image has stored data, but a computed border, we can do
(&ima(p)) if p is include in the image definition domain.
-But we cannot do that if p is include int the image extended domain.
+But we cannot do that if p is include in the image extended domain.
@@ -78,10 +82,10 @@
**** Definition
- The data property indicates how the image handle the value.
+ The data property indicates how an image get its value.
The value can be either computed (on the fly) or stored.
We say that a value is stored when we can takes a reference of it (&ima(p))
-Value stored can linear:
+Value can be stored in linear buffers:
| | |
v v v
@@ -99,7 +103,8 @@
**** Note
-computed data property implies that the image type has to be read_only.
+
+ Computed data property implies that the image type has to be read_only.
*** io
@@ -121,26 +126,19 @@
*** Speed
-
speed: slow,
fast,
fastest
**** Definition
- Give us information the time needed to access to a value from a site.
+ Give us some information about the time needed to access to a value from a
+site.
slow: ima(p) is greater than O(1)
fast: ima(p) is in O(1)
fastest: ima(p) is in O(1)
- Do we have an extended domain?
- Can we access to the image value, directly with pointer in this
-case?
-
-
-
-
-
+ pixter + extended domain
** Properties related to I::value
@@ -178,7 +176,23 @@
access: random,
browsing
-Does this property resume psite != site?
+We also need to rename these properties.
+
+If site != psite the site can be localized (see the rle image).
+
+However, we can't access to the image directly with a site.
+We need an implementation detail which is contained into the psites.
+So a site contains less information than a psite. This implies that the
+conversion from a site to a psite is not easy. We must add to the site an
+implementation detail which we can find with the image. Cast a site to a psite
+can take (a lot of) time. We can't built a psite directly from a "location".
+So the access is automatically browsing.
+
+So this property resume site != psite
+
+
+//FIXME:If site isn't localized, does psite has any sens?
+
@@ -190,11 +204,24 @@
Do we really need this property
If we look at the slice morpher, it must know that the input image is in 2d.
-So, the answer tends to be yes.
+So, the answer seems to be yes.
+
+But in this case, how do we deal with site in a no localized space?
+
+Specify the space value in localization property
+=> No, localization represents the grid, it doesn't represent the space.
+An image can be in 2 dimension and have a regular grid.
+So we need a new property.
+Perhaps, we just need to add the none value:
+
+
+ dimension: none,
+ one_d,
+ two_d,
+ three_d
+
+The dimension none is useful for image which are not localized.
-But in this case, how do we deal with no localized site? Specify the space
-value in localization property.
-Add a new value/property?
*** support
@@ -205,7 +232,7 @@
This property will certainly change.
Support property represent the underlying support of an Image type.
-It can be a grid, (regular, orthogonal, linear, isotrope, anysotrope).
+It can be a grid, (regular, orthogonal, linear, isotrope, anisotropy).
It can be different from a grid (a mesh?). We also want to know the value of a
grid "stride (pas)", if this value is different from 1. Mask and convolution
directly depends on these properties. Most of the filter mask are developed to
@@ -231,6 +258,8 @@
** localization
+
+
localization: none,
space,
grid < space,
@@ -243,7 +272,7 @@
this property set to space.
An image on a grid (which is not regular) has its property set to grid.
Does an image on a grid has always points as site?
-An image based on the base grid (aligned, isotrope/anysotrop, othogonal) has
+An image based on the base grid (aligned, isotropy/anisotropy, orthogonal) has
this property set to grid.
When this property are set, you can access to new information from the image.
@@ -251,10 +280,80 @@
regular_grid -> deltaX, deltaY of the grid + other grid property??
-Note: that a site can be localised without being point wise (site are localized
-by vector). Do we need a property to say that the image is composed by point?
-Furthermore, an image can be localized and have its type psite != site.
-Ex: graph image<Point2d, T> We need a new property in order to define if the
-image is localized. Is this property gives us the same information than the
-support property?
+** nsites property:
+
+ Some pset are not able to provide the number of sites in a O(1) complexity.
+For instance we can look at pset | P. This pset has all its sites restricts
+ to all its sites that satisfy a predicate P.
+So, if we want to know the number of sites inside pset | P,
+the complexity is in O(n) (we have to look at all the sites of pset).
+
+Do we want to provides this method in all the pset?.
+We can write an external function geom::nsites(ima : Image) : int.
+This function will basically count all the sites of the pset:
+ for_all(p)
+ if (ima.has(p))
+ ++count;
+ return count
+
+This function can be specialize for image/pset types that provide an access
+time in O(1).
+In this case a method nsite will be present in the pset inteface:
+ return ima.pset().nsites();
+
+So we need a pset property to define the complexity of accessing to the number
+of site.
+
+idea:
+ nsites: maintained,
+ computed
+
+** value_access
+
+Do we need a property to specify the access permission and access type from
+the value.
+We can access directly to the value of an image image.value
+
+
+
+
+** Pset interface: ?box methods
+
+//FIXME: Do we want to provides the xbox, gbox, ibox functions,
+or just provide one function to get box which is the more precise?
+If, just an unique function is provided, we can determine its return
+type (if the box returned is an ibox, gbox, xbox) with the localized property.
+
+An image pset has several possible localization (see localization property).
+
+
+So, depends on this property, an pset is able to return a box
+which contains all the sites of the image.
+
+If the image is based on a regular grid, it can return a gbox (box based on a
+regular grid). An gbox is composed by point2d.
+If the image is based on a grid, it can return a ibox. We can access to the
+image values through a couple (i, j). But each couple (i, j) doesn't represent
+necessary a point2d (anystrope, unaligned grid...).
+If the image localization is space, we can return a xbox (box which is not
+based on a grid).
+
+However, all the box can't be compute in a O(1) time.
+For instance, morphers which apply a transformation to an input image pset.
+We need to apply the transformation to all the image sites, in order to
+deduce the new box.
+Furthermore, the grid of the transformed image is not regular any more. (It
+depends on the property of the transformation).
+That's why we do not want to provide the ?box method directly in the pset
+interface for some pset type.
+But we can provide a external function which recalculate the box from an image
+geom::gbox(ima : Image) : gbox
+And this method is specialize for the image which maintain a box directly
+inside the pset type.
+
+So we need a property to get these information.
+
+idea:
+ boxed : true,
+ false
