Open axxel opened 5 months ago
Yes, I'm aware of this limitation. It's not possible to fix it in this crate. I don't know if there's a replacement, but you can roll your own.
If you're going to implement a generic one, be careful that &T
in Rust is not allowed to be unaligned. You may also need &[MaybeUninit<u8>]
type for the data if padding may be uninitialized.
I also came across this limitation. As most image processing libraries I came across use strides in bytes, they should not be in pixels imho...
I've started work on v2 of imgref, with support for byte offsets, as well as custom container types, and different integer sizes for the dimensions.
Currently it's very incomplete, unsafe, and crashing:
https://github.com/kornelski/imgref/compare/v2-preview
but if you're interested you can take it as a starting point, or contribute to it.
I recently implemented a Rust wrapper for my zxing-cpp barcode scanning library. On the c++ side I have the ImageView class that I needed to wrap/replace in Rust. I thought about using
ImgRef
for that but came to the conclusion that the pixel-sized stride implementation is not general enough. You explicitly mention video frame buffers as a potential input but it seems to me your decision to define thestride
as a factor forsizeof(Pixel)
does prohibit that use case in general.Say you have an
RGB
frame buffer (3 bytes per pixel) of size 2x2 but your video hardware insist to start each row on a 4-byte aligned address. So the first row starts at addressp : *const u8
, then the next starts atp + 8
but you can't specify that as anImgRef
.I understand that this is a consequence of defining your underlying container as a series of pixels instead of
u8
data. Do you know of an alternative toImgRef
that allows that? Is this use-case so niche that no-one needs it anyway? I believe theQImage
class from qt also has this internal memory layout.