Image.Data and GetSubRect not compatible

[TonyCongqianWang]

Image.Data and GetSubRect not compatible

[TonyCongqianWang]

I have noticed, that instead I could use image[row, column], but what confuses me is, why both exist. Imaga.Data can go out of sync with the real image, if someone uses image[...] = ... to set individual pixel values. So what is the point of imaga.data? Backwards compatibility? One feature neat thing about image.data is that it gives you a TDepths type as return instead of an double.

It would be nice if Image.Data[...] just returns (TDepths)image[].MCvScalar.Vx instead under the hood. Also removes the need to copy data into _array which seems to be not well supported anyway

[TonyCongqianWang]

So I have noticed, that after changing the access method, everything got veeeeery slow. It is in fact so slow, that even copying the entire image for just accessing 10% of the pixels is way faster. Though I have noticed, that Data is in fact not a copy of the underlying Matrix but uses the same memory. So now I am wondering, why does image[x,y] use marshaling, which is way slower than accessing image.Data[x,y,0-3]. Are there some cases where Image Data is not synced with the underlying cv mat?

If Image[x,y] just accessed image.Data[x,y,0-3] instead, it would be way faster and still have the additional advantage of being able to check the intended range of the image if the image was created as a subimage. Right now GetSubRect is basically unusable without also using Copy. Unless no pixel values are accessed directy in C#

[emgucv]

Image<,>.Data point to the raw data array. The GetSubRect function create a new IplImage header and shared the same raw data with the parent. It doesn't allocate new managed data. The Copy function will allocate new managed data that will have [0,0] array value corresponding to the origin.

IplImage* may be removed in the OpenCV 5.0 release. If that happpens, we will removed the Image<,> class as well. I would remmend migrating to the Mat class instead.