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

Mosaic save code doesn't include any meta data. #676

Closed
iandobbie opened this issue Sep 9, 2020 · 10 comments
Closed

Mosaic save code doesn't include any meta data. #676

iandobbie opened this issue Sep 9, 2020 · 10 comments

Comments

@iandobbie
Copy link
Collaborator

The "save mosaic" button on the mosaic screen doesn't save any information about excitation, emission wavelength etc... We should use the same code as the main image saving. However this probably needs additional data associated with each image as has previously been suggested.

@iandobbie
Copy link
Collaborator Author

I plan to try and improve this a little. The association of metadata with images is not trivial as the different segments of the code get images separately. The experiment datasaver, the mosaic and the camera views all subscribe to the NEW_IMAGE event and grab the data from that event.

My plan is to replace the (data, timestamp) sent by the NEW_IMAGE event with (data, metadata), where metadata is a dictionary containing....
objective
pixel size
position
ex wavelength
em wavelength
timestamp

and any other info we can think of.

The initial changes are minimal as we can just change the subscribing sections of code to grab the timestamp out of the dictionary and continue as if nothing has changed.

Then we are update the components one at a time to utilize this metadata, eg save it for snaps, or mosaics etc....

@iandobbie
Copy link
Collaborator Author

Thinking about this more, it also connect with the idea about individual file logs #876. Not sure we need to objective as this is very slow to change so unlikely to change within an experiment, this couple to pixel size but having the pixel size with the image object is useful for eg camera view scale bars which were present but Mick killed them as changing the objective invalidated them as they used the current objective.

My first thought is to get the obvious and easy data, timestamp, em-wavelength, stage xyz position, pixel size and ensure that data is propagated to saved files for snaps and mosaics, then think about extending it.

@iandobbie
Copy link
Collaborator Author

I have added a bunch of metadata to a dict that goes with the imageData in the NEW_IMAGE event. This is now working for the save snap path from the camera view, storing more data and ensuring it is stored in the extended header for the image. Previously the extended header did not exist and imageJ actaully returned parts of the image data in these fields.

The data should be expanded, adding textual data to the label headers and including info like excitation wavelength etc...

Additionally this data should be added to the saved mosaic data, reducing the need for the associated text file as we would have the xyz positions in the image data and should help differentiate the fluorescence images from transmission.

One issue is what to do during experiments. I think we should still propagate this data but need to minimize calls to external components to find positions etc. We should check some flag to see if an experiment is running and have access to cached data in these circumstances.

@iandobbie
Copy link
Collaborator Author

I have added the code to store this metadata with mosaic code. We should probably pull the code to match the metadata dict to the mrc extended header floats into a function in the mrc.py file.

The only thing missing to make this prime time is to consider what happens during experiments. We probably need a separate codepath to pre-assign metadata values to prevent lookups, and to precalc positions so we can populate the xyz position fields.

For the mean time I think we need a flag to say in experiment, and to just not populate any metadata when we are in this mode.

@iandobbie
Copy link
Collaborator Author

There is already a flag in experiment.expriment.isRunning(). So use this to either populate the metadata array with data, including some that might require rpc calls to stage etc, or to just dump the timestamp in which is currently all the data that is returned so all that is required to keep the existing data in experiments.

@iandobbie
Copy link
Collaborator Author

I have now basically finished this development. My branch, https://github.com/iandobbie/cockpit/tree/metadata, is now working and I will clean it up a little and then push it into the master branch.

This adds :
Wavelength
pixelsize
imagepos (xyz)
exposure time
lensID
ex-wavelength
as well as continuing to have the timestamp.

This is passed as a dict with the NEW_IMAGE event to all subscribed entities. The data is then preserved on the image objects in the camera view and mosaic. Finally the data is passed to the extended header sections in saved files from the camera view (snaps) and saved mosaics.

During an experiment the behavior is basically like before only the timestamp is passed, the one difference is that this is now in a dict as the entry metadata['timestamp']

@iandobbie
Copy link
Collaborator Author

I spent a while chasing down weird edge cases and I think this is now working. I tested.....

Simulation, with and without camera wavelengths
Multi colour mosaic from the cockpit-distribution code
Real experiment, where the info passed is as before except in a dict.

I am confident that the snap and mosaic code now have an extended header and significantly more metadata. the erpriment code also works, with a slight tweak that it needs to extract the timestamp from the dict.

If there are no objections I will push this into master next week.

@iandobbie
Copy link
Collaborator Author

I have updated this slightly so that the transfer from the camera window pulls the full metadata. This means that the image gets deposited in the mosaic in the position it was taken and with the correct scale and not the current position and assuming that the current objective was used.

This adds the question of also recording the ROI and binning in the metadata, which currently not done. This ties into issue #448 as although correctly scaled the mosaic images from roi's don't get the correct offset unless they are centered on the camera.

@iandobbie
Copy link
Collaborator Author

I will pull this into the main branch if no one has any major comments on it as I am working on other stuff that builds on this, eg the zarr file format. In experiments this just dumps the timestamp into a dict and the code flow is otherwise as before, but in other states this really helps. Putting mosaic images where they were actually captured is a win, we could reinstate the camera view scale bar as this now reflects the scale of the image, not the current objective.

@iandobbie
Copy link
Collaborator Author

Push the metadata save data for snaps and mosaic into the master branch so closing this

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

1 participant