Camera-generated metadata tag inconsistency #798
Description
During research for #797, I noticed that our camera adapters attach per-frame metadata in two different ways.
Pattern 1 - MetadataSingleTag + SetTag:
Metadata md;
MetadataSingleTag mst(MM::g_Keyword_Elapsed_Time_ms, label, true);
mst.SetValue(CDeviceUtils::ConvertToString(elapsed));
md.SetTag(mst);Pattern 2 - Deprecated put():
md.put(MM::g_Keyword_Elapsed_Time_ms, elapsed);(put() is "deprecated" only informally in a code comment.)
The result, as far as I can tell, is that when your camera uses Pattern 1, you get an extra CameraLabel- prefix on the metadata keys generated by the camera.
According to unchecked LLM research, here is the usage distribution:
Pattern 1 cameras: Andor, AndorSDK3, PICAM, PrincetonInstruments, RaptorEPIX, TISCam, TwoPhoton
Pattern 2 cameras: ABS, AlliedVisionCamera, AmScope, Andor, Aravis, Atik, Basler, BaumerOptronic, DahengGalaxy, DemoCamera, Fli, Hikrobot, IDS_uEye, IDSPeak, IIDC, MatrixVision, Mightex_C_Cam, Mightex_SB_Cam, NikonKs, OpenCVgrabber, PICAM, Pixelink, PlayerOne, PointGrey, PyDevice, QSI, RaptorEPIX, Revealer, SequenceTester, SigmaKoki, Spinnaker, ThorlabsUSBCamera, TISCam, TUCam, UniversalMMHubUsb, Ximea, ZWO
(Yes, some use both, it's complicated.)
It's clear which way is the majority, but I'd like to investigate the full data path (through MMCoreJ and acquisition engines) as well as any interactions with the Multi Camera-specific tags before making any hasty conclusions.
Most likely we should standardize on Pattern 2, making sure nothing breaks if possible. (Probably some breakage will be inevitable, though, for users of the Pattern 1 cameras who rely on metadata entries.)
We might fix this as part of the #797 migration, but thought this deserves its own issue.