Adaptation to parameter changes in PlusServer about pluslib HOT 4 OPEN

2012-08-31 12:06
Tamas Heffter
I agree, plus server should be able to choose between different configuration files, and more over, it should send the transform repository persistent transforms as a transform repository message (or within the tracked frame message) to the connected clients if they requested.

2012-08-31 12:23
Tamas Ungi
How would choosing between config files work?
I only thought of adding extra attributes to matrices in the transform repository. As we store now date, time and error, we could store depth, zoom, and frequency (and any other parameters that may change image geometry). And PlusServer could choose between these (from one transform repository).

If these attributes are not given, we can give a warning, and just send the any of the given ImageToProbe transforms for backwards compatibility. (In old config files, only one is given anyways.)

2012-08-31 12:49
Andras Lasso
The need is clear: allow changing image depth without connect/reconnect.

I would suggest to use a different image stream for each depth (or any other configuration setting), because it is very hard (if not impossible) to synchronize multiple pipelines where information can abruptly change at anytime (you cannot interpolate between abrupt changes, so an infinitely small time difference can cause a large position change, etc.).

We need to have a "master" configuration file anyway, so we can just as well (and for simplicity we should) store all information related to a procedure in one XML file.

So, the proposed implementation:
Have one XML config file.
Define multiple output streams for the imaging device: one for each supported depth. Example: UsImageDepth40, UsImageDepth50, UsImageDepth60.
Define a separate calibration matrix for each stream. Example: UsImageDepth40ToProbe, UsImageDepth50ToProbe, UsImageDepth60ToProbe.
Implement a "switcher" device that can automatically redirect multiple synchronized input streams to one virtual output stream. There wouldn't be any mixing, synchronization, etc. just pure forwarding, so having discrete switches would not cause any problem. The output of the switcher could replace the different inputs (e.g., UsImageDepth40ToTracker -> UsImageToTrackerl; either defined manually or performed automatically), so a single image/transform name could be broadcasted.

<DataCollection ... >

  <Device Type="Ascension3DG" BufferSize="500" Frequency="50" LocalTimeOffset="0.0" AveragedItemsForFiltering="20" >
    <Stream Name=”Tracker”>
      <Tool Name="Probe" PortName="0" />
      <Tool Name="Reference" PortName="1" />
      <Tool Name="Stylus" PortName="2" />
    </Stream>
  </Device>

  <Device Type="SonixVideo" >
    <Stream Name=”AxialPlaneDepth40” Depth="40" ... />
    <Stream Name=”AxialPlaneDepth50” Depth="50" ... />
    <Stream Name=”AxialPlaneDepth60” Depth="60" ... />
    <Stream Name=”SagittalPlanePlane” ... />
  </Device>

  <Device Type="Switcher" >
    <Stream Name=”AxialPlane” ... >
      <Input Source="AxialPlaneDepth40" />
      <Input Source="AxialPlaneDepth50" />
      <Input Source="AxialPlaneDepth60" />
    </Stream>
  </Device>

</DataCollection>

<CoordinateDefinitions>
  <Transform From="AxialPlaneDepth40" To="Probe"   Matrix="1 0 0 -410 ..."    />    
  <Transform From="AxialPlaneDepth50" To="Probe"   Matrix="1 0 0 -710 ..."    />    
  <Transform From="AxialPlaneDepth60" To="Probe"   Matrix="1 0 0 -910 ..."    />    
</CoordinateDefinitions>

2012-08-31 12:52
Tamas Heffter
This approach sounds good to me, but not sure Transform repository is ready for these custom fields (it needs to now which transform to use).
What if we add another xml structure to store all the different calibration results and on pre-defined settings change (like depth) we just update the current transform repository with the right calibration file. For this, data collector should get a notification to update transform repository (and it needs to have access to transform repository) with transform selected.

<CalibratedCoordinateDefinitions>
    <Transform From="Image" To="TransducerOriginPixel"
      Matrix="1 0 0 -410 0 1 0 5 0 0 1 0 0 0 0 1"
      Date="2011.12.06 17:57:00"
      DepthMm="50"
    />
    <Transform From="Image" To="TransducerOriginPixel"
      Matrix="1 0 0 -410 0 1 0 5 0 0 1 0 0 0 0 1"
      Date="2011.12.06 17:57:00"
      DepthMm="60"
    />
</CalibratedCoordinateDefinitions>

2012-08-31 12:59
Andras Lasso
It would make the programs extremely complicated if a transform could not be defined by its (from,to) name.

Instead of changing the transform repository we can just let the switcher update the transform names. The switcher can easily do that by creating an alias in the transform repo: AxialPlaneToAxialPlaneDepth40=[identity].

2012-08-31 13:14
Tamas Heffter
I like Andras' approach, however it will take a while we could implement it (it depends on the stream based data collection).
@pinter Do you have any estimate when could you finish the task #461?

2012-08-31 14:09
Csaba Pinter
It all depends on the priorities. Now my focus is not on Plus.
If it is needed for your work, maybe you could contribute.

2013-06-05 14:00
Adam Rankin
(In plus:2841) re #582 Ensuring proper destruction of data collector when a new device set is constructed

2013-06-05 14:01
Adam Rankin
(In plus:2842) re #582 vtkSonixVideoSource is no longer a singleton. It still behaves like a singleton due to static member variable pointing to the latest created instance, but this allows a future implementation of the SDK to enable non-singleton behaviour

2013-06-05 14:24
Adam Rankin
(In plus:2843) re #582 correct param name for depth and removing garbage code

2013-06-05 14:33
Adam Rankin
(In plus:2844) re #582 checking probe id to enable plane switch detection

2013-06-05 14:48
Adam Rankin
(In plus:2845) re #582 correct parameter lookup when probeid changed

2013-06-05 15:00
Adam Rankin
(In plus:2846) re #582 correctly initializing variable, investigating timeout when requesting param details

2013-06-05 17:01
Adam Rankin
Summary changed from Adaptation to depth changes in PlusServer to Adaptation to parameter changes in PlusServer

2013-06-11 15:17
Adam Rankin
(In plus:2852) re #582 typo in configuration toolbox

2013-06-18 14:39
Adam Rankin
(In plus:2862) re #582 replacing device id with channel id

adding reply status reporting in igt messages

fixing crash in plus server

2013-06-18 17:02
Adam Rankin
(In plus:2864) re #582 enabling scan plane switch handling for bk pro device

2013-06-18 19:09
Andrey Fedorov
(In plus:2865) re #582 scan plane switching in the bk, bug fixes and enabling autoUpdate

2013-06-24 15:04
Adam Rankin
re #582 adding result handling to channel ID request command and preventing disc capture device from returning its fake output channel as a valid output channel
Committed to: plus
In plus:2868

2013-06-24 15:36
Adam Rankin
re #582 adding custom attribute concept to channels
Committed to: plus
In plus:2869

2013-06-24 16:00
Adam Rankin
re #582 fixing linux build
Committed to: plus
In plus:2870

2013-06-24 21:43
Adam Rankin
re #582 readability of volume reconstruction command
Committed to: plus
In plus:2871

2013-06-27 13:09
Adam Rankin
re #582 second half of bk plane depth switching, not sure why I didn't commit this earlier
Committed to: plus
In plus:2876

2013-06-28 14:14
Adam Rankin
re #582 adding exception handling to bk device
Committed to: plus
In plus:2880

2013-06-28 14:22
Adam Rankin
re #582 forcing init of parameters
Committed to: plus
In plus:2881

2013-06-28 14:27
Adam Rankin
re #582 reducing error to warning as it seems to occurs in normal operation
Committed to: plus
In plus:2882

2013-06-28 14:50
Adam Rankin
re #582 adding guard to see if race condition is the problem
Committed to: plus
In plus:2883

2013-06-28 14:51
Adam Rankin
re #582 this .. self
Committed to: plus
In plus:2884

2013-06-28 14:56
Adam Rankin
re #582 attempting a disconnect/connect when a new plane switch is received
Committed to: plus
In plus:2885

2013-06-28 15:09
Adam Rankin
re #582 attempting lighter weight disconnect/connect
Committed to: plus
In plus:2886

2013-06-28 15:29
Adam Rankin
re #582 trying to stop sapera before param request
Committed to: plus
In plus:2887

2013-10-27 16:06
Andras Lasso
What's the status if this?
Does it work? With what devices and for what parameters?

2013-10-28 08:52
Adam Rankin
I am working on that this week. It does work, for the Sonix device only (other devices can be made to work in much shorter order). I have to complete my testing of the ImageToProbe transform being updated in order to be confident enough to check in.

from pluslib.

@Sunderlandkyl @adamrankin Now that there is the Get/Set USImagingParameters framework, would it be possible to also add in support for changing imaging depth and other fields that include pixel spacing information since that would also be changing? I didn't know if what was discussed a long time ago in this thread was still relevant or if a new approach for imaging depth had been determined.

Changing imaging depth quickly during simple live streaming would be very helpful, instead of having to stop the server and then restart with a different configuration file. Of course, I would never use it to change imaging depth during the middle of a recording, but I would change it prior to beginning various recordings.

Update: I see that there is a KEY_DEPTH parameter, so I guess this is more about updating the relevant pixel spacing which might change when this parameter changes.

Update2: I guess using UpdateTransform in PlusServer commands would be the correct method to update pixel spacing before starting another recording?

from pluslib.

See also #168

from pluslib.

I guess using UpdateTransform in PlusServer commands would be the correct method to update pixel spacing before starting another recording?

There are two options:

• Manage calibration outside of the imaging device. Then you would use UpdateTransform to update the appropriate transforms.
• The device provides calibration transform. In this case, when imaging depth is changed in the device then it updates ImageToTransducer transform automatically by setting CurrentPixelSpacingMm and CurrentTransducerOriginPixels member variables. This is more robust, as there can be tighter synchronization of image stream and transform. This approach is implemented in vtkPlusSonixVideoSource.

from pluslib.