Image.WrapMemory<TPixel>() overload taking stride

[Neakita]

I have pipeline in my performance crucial app module which avoids not only unnecessary allocations but also unnecessary memory copying. But i also have to save images on disk when it is requested, so i have to encode them before it, but Encoder only accepts Image as input, so i need to convert my raw TPixel data to image, i can use Image.WrapMemory, but it handles only continuous memory, but i'm using crop which also avoids copying by utilizing CommunityToolkit.HighPerformance Span2D which have Slice method and produces discontinuous memory area, and i can't use it's data without copy to some new instance of Image and therefore i can't encode it and save to disc. So i need some kind of Image.WrapMemory overload which accepts something like pitch as it is in Span2D (void*) constructor

[JimBobSquarePants]

but i'm using crop which also avoids copying by utilizing CommunityToolkit.HighPerformance Span2D which have Slice method and produces discontinuous memory area

No it doesn’t. We have no dependencies.

[Neakita]

but i'm using crop which also avoids copying by utilizing CommunityToolkit.HighPerformance Span2D which have Slice method and produces discontinuous memory area

No it doesn’t. We have no dependencies.

I mean in my application I use this method to avoid copying memory.

[Neakita]

Right now there is no way to wrap memory in an image that has gaps (for example due to cropping), perhaps it would be possible to add an overload that accepts the size of the gaps in each line in the same way it is made in CommunityToolkit Span2D constructor

[antonfirsov]

Pitch (aka. stride) is a concept ImageSharp memory model doesn't support currently. Discontiguous memory means something else for us: different parts of the image may live on completely different memory locations, allocated separately.

Implementing stride would require a non-trivial amount of work involving a lot of refactoring. Unless there is high interest, it's unlikely the core team will get to it. Personally, I would be fine with a community contribution.

I recommend to edit the title (Image.WrapMemory<TPixel>() overload taking stride) and the description of this discussion to make it more clear what is this feature request about, so other people possibly landing on this discussion can upvote/comment.

[Neakita]

Implementing stride would require a non-trivial amount of work involving a lot of refactoring. Unless there is high interest, it's unlikely the core team will get to it. Personally, I would be fine with a community contribution.

My end goal in this case is just to compress the image to png. Maybe it will be easier for me to take the png encoder code and adapt it to use span 2d or approach this task in some other way because it also seems to me that my use case is very specific and will not often be encountered by other library users.

[Neakita]

Pitch (aka. stride) is a concept ImageSharp memory model doesn't support currently. Discontiguous memory means something else for us: different parts of the image may live on completely different memory locations, allocated separately.

Doesn't the fact that MemoryGroup.Wrap (which is used in Image.WrapMemory method) accepts a params array play a role in this use case?

[antonfirsov]

That method allows to construct the image from multiple uniformly sized memory buffers. As far as I understand you still need a single buffer, so there would be only one Memory<T> passed to that method. The equivalent of the Span2D(void* pointer, int height, int width, int pitch) from the CommunityToolkit would be a logic that allows defining a stride when interpreting the underlying buffer(s) in Buffer2D<T>, changing the indexing equation from y*width+x to y*stride+x. Actually, it might be less difficult to implement than I initially though, but I still expect some surprises.