Task #11827 (closed)
Opened 10 years ago
Closed 10 years ago
Bug: C++ pixel buffer implementation
Reported by: | rleigh | Owned by: | rleigh |
---|---|---|---|
Priority: | minor | Milestone: | Unscheduled |
Component: | Bio-Formats | Version: | 5.0.0-beta2-RC3 |
Keywords: | cpp | Cc: | |
Resources: | n.a. | Referenced By: | n.a. |
References: | n.a. | Remaining Time: | n.a. |
Sprint: | n.a. |
Description
The Java implementation uses byte[] arrays. These have been replicated in C++ as std::vector<uint8_t>. However, this approach is fairly limited, since we could make it use the correct pixel type for ease of use and type-safety, as well as having correct dimensions of the contained pixel values to permit passing it to other methods etc.
Suggestion:
- PixelBufferBase? base class from which PixelBuffer?<T> is derived. The latter is templated, but the untemplated base means the buffer can be passed to non-templated function.
- The base class can contain generic metadata such as the dimensions and sizes of the buffer
- Plus templated accessors (which could include index operators)
This can be passed around to openByte/saveBytes and the metadata binData methods, used internally by readers, etc.
Change History (4)
comment:1 Changed 10 years ago by rleigh
- Owner changed from mlinkert to rleigh
comment:2 Changed 10 years ago by rleigh
- Keywords cpp added
comment:3 Changed 10 years ago by rleigh
- Status changed from new to accepted
comment:4 Changed 10 years ago by rleigh
- Resolution set to fixed
- Status changed from accepted to closed
PR ready now.
https://github.com/openmicroscopy/bioformats/pull/1204
Adds support for 9D pixel data arrays of any supported pixel type and endianness. Summary of the design:
Opening for initial review of the design but not yet for merging. This is the result of a few iterations of the design, which I feel now covers the needed uses well, at least at a basic level (storage and object structure); the API isn't fully complete. This should handle a large portion of the content of FormatTools?, and will later on also be able to replace the use of plane indices entirely when we switch to a truly nD API; for now it will be limited to 2D when using the existing openBytes interface. The range ctors/methods will allow specification of extents in all dimensions and so could be an alternative overloaded openBytes method (just pass in the buffer alone, which contains all the parameters you would normally provide in addition to the buffer).
I'll be adding additional functionality including: