Feature #2526
closedUse navigator iterative move in target adjustment if it was used in acquiring the parent image
Added by Anchi Cheng about 11 years ago. Updated almost 11 years ago.
0%
Description
This has prevent this very popular move method to be used when image shift is used in the acquisition node that requested the target adjustment under queuing situation.
This will also make bad goniometer problem less obvious since people can get to the position this way even when target adjustment is made such as the case of Issue #2524
Files
| myami_17939.png (88.8 KB) myami_17939.png | Jian Shi, 10/14/2013 10:40 PM | ||
| parent_move.png (182 KB) parent_move.png | Jian Shi, 10/14/2013 11:28 PM |
Updated by Anchi Cheng about 11 years ago
- Status changed from New to Assigned
- Priority changed from Normal to Urgent
Here is my idea since I can't work on it yet. Create a table for iterative move settings and reference it from AcquisitionImageData or EMTargetData. This way target transformer can use it in reacquire function.
Updated by Anchi Cheng about 11 years ago
r17925 does this. This was briefly tested a week ago. All MSI applications need new bindings
TransformManager (node alias Target Adjustment) -- MoveToTargetEvent -> Navigator (alias Navigation) Navigator (alias Navigation) -- MoveToTargetDoneEvent -> TransformManager (alis Target Adjustment)
r17927 add the bindings to application xml files with updated names
Updated by Anchi Cheng about 11 years ago
As is, it does not move by navigation if the parent is simulated.
Updated by Jian Shi about 11 years ago
Anchi,
I am running version 17931 with latest application 3.0 today. I use tomography application, but notice the preview behave odd that might relate to this new feature.
When I submit preview target, it will go through all parent images in navigator even though the preview node setting only ask for ONE parent image. It creates problem since I have inserted objective aperture at this step, and low-mag image are always get blocked.
In addition, I notice the eccentric-height will fall back to the value where the atlas was taken, and not updated to local eccentric-height of squares later, thus the focus are wrong in preview images.
I haven't try other applications, but all might have same problems.
Jian
Updated by Jian Shi about 11 years ago
Anchi,
I tried MSI_Raster quickly and see two more abnormal behaviour might related to this new application change.
1) The Z-focus sequence was actually was executed twice, it seems to me that first one just use transform without navigator, the second one use navigator to center the Z-focus target.
2) Same as preview, the z-encentric-height will be reset to the earliest one with gr during any target transform but not updated to local z-height determined in sq or hl images.
Too bad, I also can't use older application for comparing now.
Jian
Updated by Jian Shi about 11 years ago
- File myami_17939.png myami_17939.png added
Anchi,
I installed latest 17939 version but got error while creating a new session. See attached screencopy. Thus client was not connected.
Instead, I can return to old session before upgrade without issue to connect client.
Jian
Updated by Jian Shi about 11 years ago
- File parent_move.png parent_move.png added
I had errors when I check "use ancestor image mover...". Thus I had to choose no ancestor image. Choosing one/all also generate same errors, even I didn't check the box below.
Also, the most severe issue is that the Z-height simply fall back to oldest value starting on atlas, but not updated to local Z-height of gr or hl images. It occurs regardless the setting in the target adjustment.
Updated by Anchi Cheng about 11 years ago
fixed the two bugs
r17940 (related to #2551) found in creating new session now that hidden may be true in the database.
r17941 adds the missed commit of event.py
I've been working on the z reverting problem today but still can't get it to work right. Will have to continue tomorrow. This is caused by the same problem as in issue #2540 It is a bit complicated.
Updated by Anchi Cheng about 11 years ago
- Status changed from Assigned to In Test
- Assignee changed from Anchi Cheng to Jian Shi
r17951 should fix this. I left a lot of print to terminal for now. If there is still problem in this area, please send me these printing which can help with debugging.
Updated by Jian Shi about 11 years ago
I tested v17954 with MSI_RCT 3.0. Here list of what I observed.
1) If the 'parent mover' unchecked in setting, all acquisition nodes will use either navigator or preset manager to move to target. All focus nodes however simply use the target transform, ignoring the navigator.
2) If the 'parent mover' checked in setting and the set to 'one' parent image, the Exposure node will use hl as parent image to navigate the target, but focus node will use gr as parent image to navigate the target for once. If it is set to take final fc image, then focus node will use hl as parent image to center the target.
3) The focus node recall the latest Z-value out of Z-focus node correctly. However, if there are addition Z adjustments in focus node, exposure node seems not able to update to new local Z-value.
Since my testing grid is quite flat, I need more test to confirm this.
Updated by Anchi Cheng about 11 years ago
- Status changed from In Test to Assigned
- Assignee changed from Jian Shi to Anchi Cheng
The case for RCT is particularly complicated. I will need scope testing time to get this right. It has been really hard to get scope time at the moment, though.
(1) and (2) The part about navigator move not used in focus node is an old bug. No one I know has used the mover nor all ancestor target adjustment in focuser node because it does not require great accuracy.
(3) This is unlikely as the binding for Focus to Exposure is the same as for Z Focus to Hole or "Centered Square". I don't see problem in simulation but again, scope time would be needed to be sure.
Updated by Anchi Cheng about 11 years ago
- Assignee changed from Anchi Cheng to Jian Shi
r17963 changes the move in focus sequence also with moveAndPreset.
Jian,
RCT does not use TargetAdjustment node to adjust target. It has its internal algorithm. Therefore it will always do equivalent of one ancester and presetmanger mover regardless of your settings.
Updated by Anchi Cheng almost 11 years ago
- Status changed from Assigned to Closed
Feature is complete but Jian does not need it any more since their compustage was fixed. No one to test it beside me.