5 Mar
2008
5 Mar
'08
11:53 a.m.
https://svn.lrde.epita.fr/svn/oln/trunk
Index: ChangeLog
from Thierry Geraud <thierry.geraud(a)lrde.epita.fr>
Augment tutorial on image types.
* milena/doc/tutorial/image_types.txt: Augment.
image_types.txt | 129 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 128 insertions(+), 1 deletion(-)
Index: milena/doc/tutorial/image_types.txt
--- milena/doc/tutorial/image_types.txt (revision 1763)
+++ milena/doc/tutorial/image_types.txt (working copy)
@@ -59,6 +59,14 @@
for all v of ima.values
| print v.
+For such image types, we have several points (sites) associated with a
+single value cell. It is rather different from having couples (p,v);
+we actually have one value cell -> a set of points. Such data
+structure allows for compressing data because each value cell is
+shared by several points.
+
+*** Example 1
+
Consider for instance the following image:
+-----+
@@ -67,6 +75,8 @@
| 22 |
+-----+
+We have one value per run.
+
The value type is int_u2 (unsigned integer on 2 bit), that is, the
type of the interval [0,3] of N. The image is defined by a run-length
encoding with a single value per run. Precisely, this image is:
@@ -93,6 +103,115 @@
v v v
{ ((a,1),2), ((b,3),1), ((c,2),2) }
+**** A clue?
+
+***** part 1
+
+When we have value cells, it is usually related to the fact that the
+image is not point-wise writable. For instance, with the image type
+having one value per run, the operation "ima(p) := v" is not possible.
+Otherwise, that would mean that a run is split on such a write access,
+which is too slow (thus not allowed).
+
+Some rare image types can be both point-wise writable and value cell
+iterable. For instance:
+
+ image<int_u8> data;
+ map<int_u8, rgb_3x8> lut; // with i != j => lut[i] != lut[j]
+ map<rgb_3x8, int_u8> reverse_lut;
+
+The keys, resp. the values, of the lut are the values, resp. the keys,
+of the reverse_lut. With this structure, we can have a rather efficient
+point-wise writable image.
+
+ima(p) <- v {
+ it <- reverse_lut.find(v)
+ if (it is not found)
+ ++n
+ lut(n) <- v
+ reverse_lut(v) <- n
+ data(p) <- n
+ else
+ data(p) <- it.key
+}
+
+***** part 2
+
+When an image is value-wise writable, we can form:
+ ima.value(red) = blue;
+It means that we can quickly access to the cell (or the cells)
+having the value 'red'.
+
+When an image is value-cell writable, we can have:
+ for v in ima.values()
+ ima.cell(v) = v'
+In that case, a 'v' is a value cell, not a value.
+
+***** part 3
+
+Is the notion of value-wise readable relevant?
+ ima.value(red) // read-access
+gives:
+ - red, which is dummy!
+or - the corresponding point set, which can be great!
+
+This is another property...
+
+
+*** Example 2
+
+Consider this image type:
+
+{ data + +-----------+
+ | 0 2 1 0 2 |
+ | 0 0 3 2 1 |
+ | 2 1 2 2 0 |
+ +-----------+;
+ lut + +---+---------------+
+ | 0 | (255, 0, 0) | red (r)
+ | 1 | (127,127,127) | medium grey (m)
+ | 2 | ( 0, 0,255) | blue (b)
+ | 3 | (127,127,127) | medium grey (m) again
+ +---+---------------+
+}
+
+This image is defined with a look-up table; its external
+representation actually is:
+
+ +-----------+
+ | r b m r b |
+ | r r m b m |
+ | b m b b r |
+ +-----------+
+
+(conversely, the internal representation is the 'data' image.)
+
+We have I::value = rgb_3x8
+so the image appears to be highly quantized (24 bit).
+
+Yet the number of possible values is limited (here up to 4, even if
+two value cells are identical) and stored by the image in the look-up
+table.
+
+It leads to:
+ code A) rbmrbrrmbmbmbbr
+ code B) rmb
+ code C) rmbm
+
+ima.destination (browsed by code B) is an instance of
+value::subset<rgb_3x8>.
+
+FIXME: OR (?)
+
+It leads to:
+ code A) rbmrbrrmbmbmbbr
+ code B) impossible because 24bit data
+ code C) rmbm
+
+and I.destination gives value::set<rgb_3x8>.
+
** associated types
@@ -232,7 +351,15 @@
|
+ -- high
-****
+**** low
+
+I::value defines a set of possible values whose cardinality is less
+than or equal to 2^16.
+
+FIXME: OR (?)
+
+I.destination (same definition)
+
*** value
|