Warning: Can't synchronize with repository "(default)" (/home/git/ome.git does not appear to be a Git repository.). Look in the Trac log for more information.
- Timestamp:
-
03/05/16 21:34:03 (8 years ago)
- Author:
-
rleigh
- Comment:
-
Legend:
- Unmodified
- Added
- Removed
- Modified
-
|
initial
|
v1
|
|
| 1 | 1 | It depends on what type of interface we want to expose really. |
| 2 | 2 | |
| 3 | | ImageJ uses uint8 with 0 and 255 as the valid values. The C++ interface likewise uses uint8 with 0 and 255 as the valid values |
| | 3 | ImageJ uses uint8 with 0 and 255 as the valid values. The C++ interface likewise uses uint8 with 0 and 255 as the valid values--as a POD class with conversion to and from bool to make its usage as a bit type completely transparent. |
| 4 | 4 | |
| 5 | 5 | I think if the Java API did that as well, that would be compatible with the existing behaviour (is Bio-Formats also using 0/255 ?). That would mean no big changes. In this case it's really specifying the semantics of what a byte means--by constraining it to min/max and not allowing grey levels for BIT and allowing the full range for UINT8. The rest of the behaviour would remain unchanged. |
| 6 | 6 | |
| 7 | 7 | The main reason in C++ for not packing into bits is that the minimum size for array addressing is a byte, so it's not possible to easily index and subset an array if you also need to repack it. You then also have to handle trailing bits when not a multiple of 8; this means that you can't divide by the pixel type size to get the total number of pixels. That constraint would also apply to Java. In general, it's a bit wasteful of memory but it's vastly more flexible and simple to deal with. |
| 8 | | |
1.3.13-PRO © 2008-2011
Agilo Software all
rights reserved
(this page was served in: 0.44471 sec.)
