sim experiment - excitation wavelenght on dv extended header

[carandraug]

The base header of a mrc file has the emission wavelength. For SIM reconstruction we need the excitation wavelength. The mrc format does not have a place for this. The dv format seems to store it on the extended header but we don't have the specs for that.

This issue is point 2 on issue #288

We need to ask GE for the extended header specs and/or see what bioformats does. Seems like the OME team have some specs for the extended header but are unable to share them. We should be able to guess from their source code . See also bioformats page on the dv format and a recent bug report about wanting more up to date specs

[carandraug]

The fix seems to be that we will have cockpit writing dv files. What I gathered from reading the source bioformats and other dv readers, other than setting the right id on the mrc header, this would mean that the extender header becomes an array of 14 floats per plane. Each group of 14 floats the same order of the image planes on the data section. They will be order like so:

1. photosensor reading, typically in mV
2. elapsed time in seconds since experiment began
3. x stage coordinates
4. y stage coordinates
5. z stage coordinates
6. minimum intensity
7. maximum intensity
8. mean intensity
9. exposure time in seconds
10. neutral density (can be either a fraction of 1 or a percentage)
11. excitation wavelength
12. emission wavelength
13. intensity scaling (usually 1)
14. energy conversion factor (usually 1)

[iandobbie]

Carnë Draug <notifications@github.com> writes:

The fix seems to be that we will have cockpit writing dv files. What I gathered from reading the source bioformats and other dv readers, other than setting the right id on the mrc header, this would mean that the extender header becomes an array of 14 floats per plane. Each group of 14 floats the same order of the image planes on the data section. They will be order like so: 1 photosensor reading, typically in mV 2 elapsed time in seconds since experiment began 3 x stage coordinates 4 y stage coordinates 5 z stage coordinates 6 minimum intensity 7 maximum intensity 8 mean intensity 9 exposure time in seconds 10 neutral density (can be either a fraction of 1 or a percentage) 11 excitation wavelength 12 emission wavelength 13 intensity scaling (usually 1) 14 energy conversion factor (usually 1)

This seems like data it would be pretty easy to have or calculate and write into the header. I think it would be worth getting this sorted even if we move onto using FairSIM as the info is available and some of it is not recorded elsewhere (eg excitation wavelength in particular at present!) Ian

[iandobbie]

I think this will fix the issue in #168 as well

[carandraug]

I have started to fix this with commit carandraug/cockpit@a20c1a8

I need someone's help to actually get the required metadata which I don't know where is kept. See the three TODO's on that commit.

Where is the excitation wavelength for the each image? The CameraHandler.wavelength property is the emission not excitation, correct?

Also, I guess we could add the exposure time. There is CameraHandler.getExposureTime but if the writing of each plane is not synced with the image acquisition, then it's possible that at the time of writing, the camera exposure settings are different from the actual settings used for acquisition, correct?

[carandraug]

A side note because the only reason to have all this trouble is to use softWoRx for reconstruction.

Is the excitation wavelength information in the extended header used by softworx to create a correct call to OMXSIReconstruction? Or is the extended header inspected by OMXSIReconstruction itself? Because it seems that the excitation wavelength is a parameter to call the reconstruction program, like so:

OMXS [...] -channel_ex_linespacing $EX_WAVELENGTH $LINESPACING [...]

and so we could use it directly and not via softWoRx until we replace softWoRx.

[carandraug]

I have a fix for this on my branch extended-metadata. This seems to work for Mick with dummy devices. I have also tried it on Deepsim and the excitation wavelength is correct there. Ian, can you check if this is enough for softWoRx to do the reconstruction properly?

For this fix, we assume that all images from a specific camera have the same excitation wavelength. This is not great but according to @mickp is true if doing experiments with the cokpit interface.

I think that a long term fix for this will require passing to writeImage an image object that has the pixel values and the metadata for it. As it is, we only have the pixel values, and a timestamp from software. The rest we have to deduce from the camera that took the image.

[carandraug]

I have pushed commits 26e32f7...6ef282b after testing this on DeepSIM with Ian. This writes an extended header of 14 floats per image plane that bioformats and the ImageJ Deltavision Opener plugin can read. However, OMXSIReconstruction still fails to pick the excitation wavelength values. We don't know where OMXSIReconstruction is looking for that data.

The extended header is a group of floats and ints per image plane. The existing open source readers skip all the ints and read the first 14 floats. So the changes pushed now write only 14 floats. But reading actual dv files, it seems that it's writing 8 ints and 32 floats. We have no idea what may go on the other values, but maybe that shape of extended header is required to make OMXSIReconstruction happy:

>>> import struct
>>> fh = open(..., 'r')
>>> fh.seek(128)
>>> struct.unpack('h', fh.read(2)) # number of int
(8,)
>>> struct.unpack('h', fh.read(2)) # number of float
(32,)
>>> fh.seek(1024)
>>> struct.unpack('8i32f', fh.read(8*4 + 32*4))
(0, 0, 0, 0, 0, 0, 0, 0, 0.0, 0.0, 16640.0, 13462.0, 5520.75, -4002.38134765625, 4026.86279296875, 125.80743408203125, 60.0, 1.0, 488.0, 525.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0)

[carandraug]

Writing down 8 ints and 32 floats per plane, even though all filled with zero fixed the issue, i.e, softworx is now picking the right excitation wavelength for reconstruction. Pushed fix in commit 961a3cc. Closing as fixed.

Note that we don't know what all that new data is meant to have on the extended header. I left the code in place ready to fill the metadata if we ever get to know about them.

[iandobbie]

From the list I would take 488 as the excitation wavelength and 525 as the emission Ian

…

Sent from my iPhone On 23 Jul 2018, at 19:43, Carnë Draug <notifications@github.com<mailto:notifications@github.com>> wrote: Closed #290<#290>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#290 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AFMwhWvfVtEN8LeHbqM9MkwwP9C0nDbLks5uJhlCgaJpZM4QrqYE>.