Closed metasim closed 7 months ago
I'll have to think a bit more about this one, but I'm not sure I'm a fan. We should probably enable conversion from Buffer
to Array2
and back instead of having two separate read and write functions.
But more importantly, we should have a way to pass in a buffer instead of allocating a new one each time.
@lnicola Let me restate the use case just to make sure it's clear what I'm trying to do here.
I have an application where I do not want to include/use the ndarray
library, and I want to be able to read an image block by block. Before this PR I could not do that. Currently, block reading is only available if you are an ndarray
user.
The renaming of the existing one is clearly not required, so I can figure out some other naming if that's objectionable.
I just re-read your comment. If what you're arguing is that we should normalize the I/O around the Buffer<T>
type (or, perhaps even better, Vec<T>
!), then I'm even more of a fan of that, but wondered how controversial that would be.
Instantiating ArrayX<T>
from a Vec<T>
is so easy, it does seem silly to have dual methods.
Yes, I think we should use Buffer
with easy conversions to ndarray
. It's better than Vec
because it has the shape information.
I'll prototype something.
[X] I agree to follow the project's code of conduct.
[X] I added an entry to
CHANGES.md
if knowledge of this change could be valuable to users.Added ability to convert between
Buffer<T>
andndarray::Array2<T>
.Implemented
IntoIterator
,Index
andIndexMut
forBuffer<T>
.Breaking:::shape().
Buffer<T>::size
is now private and accessed via `BufferBreaking:::data().
Buffer<T>::data
is now private and accessed via `BufferBreaking: Removed
Rasterband::read_as_array
, changed signature ofRasterband::read_block
to return aBuffer<T>
.Breaking:
Rasterband::write
andRasterband::write_block
now require a&mut Buffer<T>
to handle possible case of drivers temporarily mutating input buffer.cc: @mwielocha