I'm curious how hard it might be to change to CImg addressing calculations to allow arbitrary row to row and slice to slice strides?
ie, instead of index= x + width ( y + height z ) ), index = x + y ystride + z zstride.
Where the strides would be members of CImg, defaulting to the width/height for normal images.
The application for this is that it allows creating a CImg with shared memory that refers to a subimage of another CImg. For instance, things like this would be possible:
Cimg myImage( 1024, 1024 ); ...
myImage.subimage( 10, 10, 256, 256).save_png( "blah" ); // save part of the image
myImage.subimage( 10, 10, 256, 256).draw_line(...); // draw a line clipped to [10,10,256,256]
This wouldn't introduce any incompatibilities for existing applications that expect the contiguous layout, as CImg would not normally set non-compatible strides.
rookieWanZ
commented
1 year ago
I'm curious how hard it might be to change to CImg addressing calculations to allow arbitrary row to row and slice to slice strides?
ie, instead of index= x + width ( y + height z ) ), index = x + y ystride + z zstride.
Where the strides would be members of CImg, defaulting to the width/height for normal images.
The application for this is that it allows creating a CImg with shared memory that refers to a subimage of another CImg. For instance, things like this would be possible:
Cimg myImage( 1024, 1024 ); ...
myImage.subimage( 10, 10, 256, 256).save_png( "blah" ); // save part of the image myImage.subimage( 10, 10, 256, 256).draw_line(...); // draw a line clipped to [10,10,256,256]
This wouldn't introduce any incompatibilities for existing applications that expect the contiguous layout, as CImg would not normally set non-compatible strides.
Thanks for the great image library!