[WIP] libuca changes

[MarcusZuber]

I will put here all my changes in libuca im currently working on. So far nothing will break anything existing.

• Metadata
  • A plugin can implement grab_with_metadata, where a pointer to a GHash-table with arbitraray metadata is porvided.
  • If it is not implemented, the normal grab is used and an empty hash table is added
• Color/Mutlichannel
  • A property num_channels is added to the base camera. This can be set to 3 for color or an arbitraty other value (e.g. for specroscopic detectors)
  • The frame buffer will hold the whole data like pixel1_chan1, pixel2_chan1, pixel3_chan1,... pixel1_chan2, pixel2_chan2,...
  • A function get_chanel(buffer, int channel) will be added to get the "sub image".
• Currently, at mutliple places it is hardcoded, that a pixel is sored as 8 or 16 bit. This I will make completely free, using the bytes_per_pixel property. In the current implementation, the property can be set to anrbitrary value, but works currently only with 1 or 2.
• Mutexes
  • There is something wrong with the ring-buffer mutexes. I will fix this.

Question:

• Should I move the grab_send to the base-camera?
  • With this the implementation in concert of the uca-camera and remote-uca-camera would be the same.

[tfarago]

• A function get_chanel(buffer, int channel) will be added to get the "sub image".

How would I grab then a color image, with three separate calls?

[tfarago]

• Should I move the grab_send to the base-camera?

I think @matze had some convincing arguments why to put grab_send to ucad and not the camera itself in ufo-kit/uca-net#13, unfortunately the conversation was wiped with force-pushing.

I'd say if not strictly necessary leave it where it is.

[MarcusZuber]

• A function get_chanel(buffer, int channel) will be added to get the "sub image".

How would I grab then a color image, with three separate calls?

I would suggest that the 'client' calls grab and then splits the (multichannel) buffer regarding the num_channels using the get_channel(buffer, i) function. This would make sure, that if the client does not handle the multichannel data correctly, you would still save the whole image and could "descample" it in post-processing.

[MarcusZuber]

• Should I move the grab_send to the base-camera?

I think @matze had some convincing arguments why to put grab_send to ucad and not the camera itself in ufo-kit/uca-net#13, unfortunately the conversation was wiped with force-pushing.

I'd say if not strictly necessary leave it where it is.

It would add zmq as a dependency to libuca and not only to uca-net.

I use "local" uca-cameras with remote writers (using the grab_send of the concert base camera). Did you ever compare the performace? I could imagine, that it would be faster if the plugin splits the data insted of first copy it to python and then sending it to the receivers.

[tfarago]

• A function get_chanel(buffer, int channel) will be added to get the "sub image".

How would I grab then a color image, with three separate calls?

I would suggest that the 'client' calls grab and then splits the (multichannel) buffer regarding the num_channels using the get_channel(buffer, i) function. This would make sure, that if the client does not handle the multichannel data correctly, you would still save the whole image and could "descample" it in post-processing.

I would think of the downstream tasks and they should not need to do anything special. E.g. a writer should get an RGB image and write it like usual, same for viewer, at least for the "standard" color images.

[tfarago]

• Should I move the grab_send to the base-camera?

I think @matze had some convincing arguments why to put grab_send to ucad and not the camera itself in ufo-kit/uca-net#13, unfortunately the conversation was wiped with force-pushing.
I'd say if not strictly necessary leave it where it is.

It would add zmq as a dependency to libuca and not only to uca-net.

I use "local" uca-cameras with remote writers (using the grab_send of the concert base camera). Did you ever compare the performace? I could imagine, that it would be faster if the plugin splits the data insted of first copy it to python and then sending it to the receivers.

Unless your cameras go with like 10 GB/s (note the capital B) I don't think this will be an issue. But I see your point and whereas from software engineering point of view this may feel wrong, from the practical usage it definitely makes sense.

[MarcusZuber]

• A function get_chanel(buffer, int channel) will be added to get the "sub image".

How would I grab then a color image, with three separate calls?

I would suggest that the 'client' calls grab and then splits the (multichannel) buffer regarding the num_channels using the get_channel(buffer, i) function. This would make sure, that if the client does not handle the multichannel data correctly, you would still save the whole image and could "descample" it in post-processing.

I would think of the downstream tasks and they should not need to do anything special. E.g. a writer should get an RGB image and write it like usual, same for viewer, at least for the "standard" color images.

Yes, for the standard way I would directly implement something in uca-grab and concert. If you use (nx, ny, 3)-dim numpy arrays, most of our libraries are already assuming rgb.

But I also have much more crazy cameras with 8 channels. I just read that tiff supports 2^16 channels per pixel 🫤 .