Ticket #47 (closed defect: fixed)

Opened 11 years ago

Last modified 10 years ago

libGenFile: read Metamorph 'Z plane position' attribute

Reported by: emmenlau Owned by: emmenlau
Priority: major Milestone:
Component: xuvtools Version:
Keywords: libGenFile, Metamorph, stage, coordinates, attribute Cc: aaron@…

Description

Now, the microscope stage is supposed to return to some z = 0 level before acquiring the next tile, and thus features should all be at the same level in the file. This was obviously not the case in DS's dataset. Interestingly, we opened the files in Metamorph and found out that besides the well known x and y stage positions, Metamorph saves also a 'Z plane position' (not stage, plane...) somewhere in the file (in this case at least, it was is low, negative integer). Each file had a different number, implying that Metamorph actually knew that the stage was not going back to the same z level every time. So, we set that number as z coordinate for each of the files in the PositionEditor? (and also dragged the tile with the large xy error on its approximate position) and we told the stitcher to start from there and we got basically a perfect stitch.

Attachments

stitcher_log.txt Download (10.4 KB) - added by emmenlau 11 years ago.
Metamorph metadata with imgcnv-09.07.04

Change History

Changed 11 years ago by emmenlau

Dataset at xuvtools.org:/data/xuvtools_img/BugListData/Bug0047

Changed 11 years ago by aaron@…

I cannot find where we wrote about the related problem of the z voxel size not being read from files, so I will add it here. From Metamorph files, the z calibration (z step) is not read.

Changed 11 years ago by emmenlau

That was in  http://lmb.informatik.uni-freiburg.de/trac/ticket/61 "libGenFile: read Metamorph 'Z voxel size' attribute". It is fixed in my local revision, sorry I forgot to commit *blush*!

Changed 11 years ago by aaron@…

Great, thanks.

Changed 11 years ago by emmenlau

Metamorph metadata with imgcnv-09.07.04

Changed 11 years ago by emmenlau

Dmitry has implemented the needed code to interpret the "stage_position_z" attribute of Metamorph STK stacks in his libbioimg. However, there is something strange about the stage_position_z, as you can see in the attached logfile (here a sorted excerpt). The stage_position_z_plane_X changes by a huge step between planes. Does that make any sense?

stage_position_x 1514.800000 stage_position_y -923.390000 stage_position_z 13.500000 stage_position_z_plane_000 13.500000 stage_position_z_plane_003 0.940000 stage_position_z_plane_005 0.000186 stage_position_z_plane_006 0.000036 stage_position_z_plane_007 3.000000 stage_position_z_plane_008 0.000000 stage_position_z_plane_009 0.000000 stage_position_z_plane_010 0.000000 stage_position_z_plane_011 0.000000 stage_position_z_plane_013 0.035294 stage_position_z_plane_015 0.085938 stage_position_z_plane_016 0.187500 stage_position_z_plane_018 0.000214 stage_position_z_plane_019 0.150000 stage_position_z_plane_020 0.000000 stage_position_z_plane_021 0.000000 stage_position_z_plane_022 0.133333 stage_position_z_plane_023 4.750000

Changed 11 years ago by emmenlau

Proposed fix in  http://data.xuvtools.org/intern/imgcnv-09.07.03.tar.bz2 together with subversion r2756.

Changed 11 years ago by aaron@…

This is indeed strange. Also for x and y coordinates the Metamorph file stores one entry per plane, but they are always all identical. At least in this example, the entry 'stage_position_z' (13.500000) is the one that Metamorph returns in the File Info. Maybe in the z case the stage_position_z_X for X > 0 is just garbage?

Changed 10 years ago by emmenlau

  • status changed from new to closed
  • resolution set to fixed

I will close this bug, since there have been no new reports and no progress in 6 months.

Note: See TracTickets for help on using tickets.