Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support mmc.getTaggedImage #17

Closed
oeway opened this issue Sep 5, 2020 · 4 comments
Closed

Support mmc.getTaggedImage #17

oeway opened this issue Sep 5, 2020 · 4 comments

Comments

@oeway
Copy link
Contributor

oeway commented Sep 5, 2020

The java interface has the getTaggedImage function, perhaps would be good to also make it available in the Python binding?

@marktsuchida
Copy link
Member

@oeway This is a good point. The problem is that TaggedImage is a Java type, and one that we would like to phase out in the long term due to multiple issues (it exposes public data fields (bad in Java unlike in Python), and uses an antiquated version of JSONObject as part of its API).

(Also, much of the logic for putting together a TaggedImage is in MMCoreJ.i, rather than the common MMCore code.)

It would be nice to have something similar in Python, though. If adding such a thing, it would be good to learn also from a few more design mistakes that TaggedImage made: it puts metadata from different sources into a single bag, and string-concatenates device and property names with "-", so that unambiguous parsing is not possible.

@tlambert03
Copy link
Contributor

tlambert03 commented Aug 17, 2023

fwiw, this was added to pymmcore-plus in pymmcore-plus/pymmcore-plus#246

it would be good to learn also from a few more design mistakes that TaggedImage made: it puts metadata from different sources into a single bag, and string-concatenates device and property names with "-", so that unambiguous parsing is not possible.

I very much agree with this. I implemented it as a match for now. but would love to see a better/formal spec for what those tags should actually be. this relates also to AcqEngJ, which continues with the pattern

@tlambert03
Copy link
Contributor

safe to close this issue as not planned @marktsuchida ?

@marktsuchida
Copy link
Member

Yes, the recommendation should be to use pymmcore-plus. There may be further improvements in MMCore and its API (rather than pymmcore, probably) to reduce overhead or more accurately define timing/concurrency, but that's a whole nother topic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants