I'm using a LMT200 stage from ITK with a Hydra controller.
When I revert the axes of the stage (stage Transpose mirror X or Y) in the
Device Property Browser of Micromanager, the stage was still moving the same
I tried Micromanager build 20180615 and also the latest nightly build that I
could find for the 1.4.23.
Has anyone experienced reverting the axes of a LMT200 stage before under
I am the "author" of the LMT 200 driver and i can confirm to you that this
feature hasn't been working since day 1 of the port from the Corvus stage to
the LMT stage. As i didn't need this feature, and no one manifested any
interest in it, i didn't look into why it wasn't working.
Now i have had a quick look this morning (and do note that i am by no means
an expert in driver writing or how micromanager's MMCore works) and it seems
that there is no current support for this feature in the Driver.
But I'm not sure that the transpose function is something that is tied to
the Driver itself or a micromanager feature that works regardless of which
driver you use. In the first case then this feature needs to be implemented.
In the second case it's a micromanager bug that should be noted.
I do have to note that my Andor camera also have transpose features that do
not seem to work when using live.
I looked in a few other Drivers and i didn't see the support for this
feature in any of the ones i checked, so i can't really tell you how easy it
can be to implement.
I also tried to revert the stage axes under the software LASX as the stage
is installed on a Leica DMi8 microscope and it did not work. This supports
strongly your hypothesis that the issue could come from the Driver itself.
We developped a plugin Micromanager to control a DMD to achieve
photopatterning of proteins.
It would be very nice indeed to have this feature in order to get proper
stitching when we deal with large images.
Not sure what exactly this was a response to since it was not included,
> I am the "author" of the LMT 200 driver and i can confirm to you that this
> feature hasn't been working since day 1 of the port from the Corvus stage to
> the LMT stage. As i didn't need this feature, and no one manifested any
> interest in it, i didn't look into why it wasn't working.
> Now i have had a quick look this morning (and do note that i am by no means
> an expert in driver writing or how micromanager's MMCore works) and it seems
> that there is no current support for this feature in the Driver.
> But I'm not sure that the transpose function is something that is tied to
> the Driver itself or a micromanager feature that works regardless of which
> driver you use. In the first case then this feature needs to be implemented.
> In the second case it's a micromanager bug that should be noted.
The very first idea is that Micro-Manager expects the stage to operate
with defined direction. To make the direction "match", Micro-Manager
pre-defines the properties "TransposeMirrorX and TransposeMirrrorY. The
settings of those properties are taken into account by the Set and
GetPositionUm functions. However, if the Device Adapter defines its own
versions of those functions and does not use the TransposeMirror
settings, then the user can no longer adjust the direction of the stage.
I do not know what the LMT 200 stage is (or the name of its Device
adapter), so I can not check the implementation, but it is possible that
all that is needed is deleting the Set and Get PositionUm functions in
> I do have to note that my Andor camera also have transpose features that do
> not seem to work when using live.
Please note that the camera "Transpose" properties are unrelated to the
stage "TransposeMirrorX-Y" properties.
What did you expect to see? The transpose properties of the camera will
not change the orientation of the image. They merely change the
relation between stage direction and image orientation. In addition, it
is possible that not all code interprets these settings correctly. If
you want to change the image orientation itself, use the Image Flipper
plugin (but this will likely interfere with the relation between camera
orientation and stage movement).
In MM 2.0-gamma, the transpose features have been superseded by a
simplified affine transform that describes the relation between image
orientation and stage movement. We will slowly remove all dependencies
on the transpose features.
> I looked in a few other Drivers and i didn't see the support for this
> feature in any of the ones i checked, so i can't really tell you how easy it
> can be to implement.
Unsure which feature you refer to, but all stage adapters that do not
override the SetPositionUm and GetPositionUm functions provide
directionality control to the user.
Thanks for the insights nico (BTW the name of the device in github is
As per what is written in the link you gave :
"Camera images can be different from the desired orientation in three ways:
they can be rotated, mirrored along the X-axis, and mirrored along the
Y-axis. All camera adapters now (as of version 1.2.15) have three properties
(TransposeXY, TransposeMirrorX, TransposeMirrorY) that describe the needed
I expected the image taken to be mirrored or rotated indeed. Currently, as
far as i'm aware after a few tests, My Andor Zyla SCMOS camera's transpose
functions don't do anything.
You have 2 choices, either you wait for me to and implement the fix but it
can take a while because i am busy with a few things (I can try and have it
done for next week or the week after), or you go ahead and try and fix it
> I expected the image taken to be mirrored or rotated indeed. Currently, as
> far as i'm aware after a few tests, My Andor Zyla SCMOS camera's transpose
> functions don't do anything.
I agree that the way this is currently handled is pretty confusing. The
mirror and transpose properties don't actually do anything to the image.
They just set a flag which other pieces of the code can check. For example,
the grid creation dialog will check the transposexy flag and it will swap
the axes of its grid points accordingly. However, many parts of the code
don't check for this property and so the end result is that these properties
Currently in order for me to get a stitchable image from a grid collection i
need to make sure that the camera's transpose property is set but I also
need to make sure that the image flipper plugin is properly rotating the
image, this seems redundant.
I'm not sure exactly how this would be implemented but it seems like a
better solution would be to have the camera device adapter actually
mirror/transpose the image buffer. That way other bits of code wouldn't be
expected to take these properties into account. This would effectively
eliminate the need for the image flipper plugin as well.