Add CACAO streams alongside data streams.

[ehpor]

This PR makes it possible to use CACAO streams as part of the service, natively distributed alongside catkit2 data streams. This simplifies the interface and makes cacao streams easier to access.

It makes data on CACAO processes visible on catkit2 services with a minimal interface. This allows catkit2 services to control a CACAO RTC. It does not however make catkit2 data streams available to CACAO processes.

There is no impact on the performance of catkit2 streams. @RemiSoummer

Todo:

• Test.
• Add error checks upon opening and closing streams.
• Use pyMilk on the Python proxy instead of bare IMAGE objects.

[RemiSoummer]

Thanks for clarifying no impact on performance of the streams.

[a-sevin]

Do you also want to handle milk's semaphores to wait and publish new data ?
It could be very useful to have the notion of slices (cnt1 for 3D buffer) to avoid data corruption.

[ehpor]

@a-sevin

Do you also want to handle milk's semaphores to wait and publish new data ?

Right now, this PR aims for very loose coupling: just distributing ImageStreamIO streams alongside proprerties, methods and data streams already in catkit2 services. Interacting with that ImageStreamIO stream would be purely via their library, so via the ImageStreamIO library itself (for C++ compatibility) or via ImageStreamIOWrap or pyMilk (for Python compatibility).

On the C++ side, the ServiceProxy returns an std::shared_ptr<IMAGE> object. On the Python side, it will be a IMAGE object via ImageStreamIOWrap, though as of yet, I'm unsure how to link that together without needing to compile ImageStreamIOWrap.cpp inside the library too. Chatgpt told me about some very interestring constructions there, that I want to explore.

All of this to say: CACAO would still own its image streams. Catkit2 would just simplify connecting to them inside a service, since you only need to write the filenames inside the service itself, and that attribute would be available to all of catkit2, already opened and ready.

I'm not burning my hands yet on full integration of CACAO streams into catkit2 via the same interface as DataStreams. It feels like they are too dissimilar to make that easy.

It could be very useful to have the notion of slices (cnt1 for 3D buffer) to avoid data corruption.

Yes. I'm still confused by what CACAO is using. I was under the impression that CACAO used ring buffers for all image streams too. But after talking to Vincent and Olivier, it seems that is not the case? While that gives obvious advantages in cache usage (the reason I was told/remember from our conversation), data corruption seems a real issue with that imo. Catkit2 uses ring buffers by default to avoid data corruption (unless the reader is so slow that the writer catches up to it in the ring buffer).

[a-sevin]

OK ! Thanks for the clarification