Although the original author mentions bits, he means bytes. It's a regular
thing that images have a row of bytes referred to as a line to ensure
alignment of each pixel row. This usually is padded with up to 15 bytes.
As the original author indicates numerous libraries do this. From image IO
(libtiff: scanline) to image processing libraries like opencv/ipp (step).
However HDF only likes packed arrays and doesn't really deal with this
notion of storage. So how can we make it deal with it not in terms of the
data space but in terms of something some detail to this particular memory
buffer? Copying images to packed format is an ugly and non-optimal
solution; a bunch of write calls isn't great either.
Although the original author mentions bits, he means bytes. It's a regular thing that images have a row of bytes referred to as a line to ensure alignment of each pixel row. This usually is padded with up to 15 bytes. As the original author indicates >numerous libraries do this. From image IO (libtiff: scanline) to image processing libraries like opencv/ipp (step).
However HDF only likes packed arrays and doesn't really deal with this notion of storage. So how can we make it deal with it not in terms of the data space but in terms of something some detail to this particular memory buffer? Copying images to packed >format is an ugly and non-optimal solution; a bunch of write calls isn't great either.
Regards,
-Jason
--
___________________________________________________________________________
Dr. Werner Benger Visualization Research
Center for Computation & Technology at Louisiana State University (CCT/LSU)
2019 Digital Media Center, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362
In general images are almost never a power of two. In various parts of my
application this holds true for the data I would like to dump to hdf. I
presently explicitly set the line step bytes to be columns * pixelsize, but
in general this is not good because many optimized functions expect each
row to start on a 16 or 32 byte boundary. Also, please keep in mind
images can be uint8, uint16, uint32, floats...
-Jason
···
On Thu, Sep 19, 2013 at 8:10 AM, Werner Benger <werner@cct.lsu.edu> wrote:
**
Would it be appropriate for your application to use a chunked dataset such
that each chunk is sized to e.g. a power of 2 ?
Werner
On Thu, 19 Sep 2013 09:36:25 -0500, Jason Newton <nevion@gmail.com> wrote:
Although the original author mentions bits, he means bytes. It's a
regular thing that images have a row of bytes referred to as a line to
ensure alignment of each pixel row. This usually is padded with up to 15
bytes. As the original author indicates numerous libraries do this. From
image IO (libtiff: scanline) to image processing libraries like opencv/ipp
(step).
However HDF only likes packed arrays and doesn't really deal with this
notion of storage. So how can we make it deal with it not in terms of the
data space but in terms of something some detail to this particular memory
buffer? Copying images to packed format is an ugly and non-optimal
solution; a bunch of write calls isn't great either.
Regards,
-Jason
--
___________________________________________________________________________
Dr. Werner Benger Visualization Research
Center for Computation & Technology at Louisiana State University (CCT/LSU)
2019 Digital Media Center, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362