Skip to content

Release Notes

Thomas Euler edited this page Sep 6, 2019 · 1 revision

Release notes for ScanM

From January 2017 on, release notes for the DLLs and the Igor part are combined. In addition, started a new, less complicated version numbering schema.

ScanM v2.10/v1.1.37.1 (2018-08-07, Development branch)

  • Rotation angle now setValue GUI element (requested by Maxime)

  • Temporary fix for potentially jumping x-y offset (reported by Maxime; needs to be tested)

  • New "warp mode" aimed at fixing the axial wobbling in bi-directional x-z scans (beta). In this context, a feature was added that allows comparing two consecutive frames (hidden in the Scan Control window, can be activated by checking the box named "misc."). This feature uses the function usr_FrameDiff() defined in usr_MyUserFunctions.ipf and can be adapted. Currently, it calculates pixel-wise the mean squared error between two frames.

  • ScanM now also runs with Igor 8 (but so far only the 32bit version). The code is not yet optimised for Igor 8 (i.e. the GUI not yet adjusted); only necessary changes have been made. Both Igor 6 and 8 use the same XOPs and DLLs (see below), therefore an Igor 6 installation can just be copied into the Igor 8 folder structure, allowing to run both versions in parallel (e.g. to test Igor 8 while backdropping to Igor 6 if needed).

  • ScanM32.dll (v1.1.37.01)

    • No new features, just converted to the XOP Toolkit 8 (still with Visual Studio 2015) to make it fit for Igor 8.

ScanM v2.08/v1.1.36.65 (Development branch)

  • Implemented Filip Janiak's banana scans (Baden lab) as well as a more general "warp" control. This feature still needs testing and user feedback (i.e. on the warp parameters). Other than in Filip's solution, all warp related parameters are saved separately for each configuration. In the ScanM header files, the warp parameters as well as the warp mode is saved as a key-value string User_WarpParam. PLEASE TEST CAREFULLY!

ScanM v2.07/v1.1.36.65 (started 2018-05-24)

  • Started implementation of Filip Janiak's banana scans (Baden lab) as a more general "warp" control ...
  • Reload current scan configuration function (via Reload button) now keeps the earlier settings (i.e. selected channels).
  • New button Reload all added to the GUI; it triggers the reloading of all scan configurations and keeps the currently selected configuration including channels. It is different from the respective menu entry, as the later also re-initialized the configuration management.

ScanM v2.06/v1.1.36.65 (started 2017-12-06)

  • Started implementation of scan sequences, e.g. a sequence of 64x64 scan fields at different positions in the tissue. To this end, a new wave (wScanSeqParams) is created for each scan configuration and is accessible to the scan path functions when the scan configurations are loaded. The wave can be filled (by the user, for each scan field in a sequence): offset voltages for all 4 AO channels to implement xyz offsets in scan field position, a zoom factor for each scan field, as well as angles for rotating the scan field around the z axis and for tilting it along the y axis. Reloading the scan configuration then applies the parameters to the next scan.
  • New button Reload added to the GUI; it triggers the reloading of the currently selected scan configuration.

ScanM v2.04/v1.1.36.65 (started 2017-08-01)

  • ScanM32.dll (v1.1.36.65)

    • invertPixels (CMD_INITIALIZE) is now interpreted as a pixel mask, allowing the user to select which AI channel should be inverted (e.g 0x00, no channel inverted; 0x01 AI0 is inverted; 0x03, AI0 +AI1 are inverted, etc.). Note that a complete restart of ScanM is needed for a change to take effect.
  • Added more scan configurations that use the ETL, such as:

    • xz-scans, with the x mirror as the fast scanner and the ETL moving the scan line step-wise vertically into the tissue (vertical "slice").
    • xz bi-directional scans, an improved version of the xz-scan, with the ETL not jumping back before the next frame but stepping back up. Should eliminate ETL vibration (?) artifact observed in xz-scans. Still to be tested.
    • zx-scans, with the ETL modulated sinusoidally at 250 Hz and the x mirror slowly advancing across the tissue, allowing to trade spatial for temporal resolution by adjusting the number of z "lines". Still being tested (Status: Image looks as if ETL cannot follow; need to check if indeed the ETL is too slow or if the lens driver does not drive the lens correctly).
  • Bug fix: ETL neutral voltage should now be kept in all phases of ScanM operation.

  • .SMH files now also contain information about the ETL settings.

  • Modification of ScM_FileIO.ipf: Many changes to accommodate the new scan configuration while staying compatible to older ScanM data files. Three cases of scan data are now considered:

    • scans that are easily to reconstruct w/o information loss (e.g. standard xy scans)

    • scans where the pixel data needs to be reordered but is loss-less (e.g. bidirectional xz scans)

    • scans that cannot be easily represented on the screen and that require a decoder to reconstruct an image, which represents an approximation (= down-sampled version) of the actually scan field. Here, the decoding may involve information loss (e.g. spiral scans).

    As a consequence, when importing pixel data for scans of the last type, both the raw data is imported (e.g. wDataCh0_raw) and a reconstructed representation (wDataCh0) is generated, using the original scan path function. In addition, the ScM_FileIO.ipf regenerates the stimulus buffers and stores them in an own data folder; these are then accessible for analysis scripts, e.g. to determine the exact timing of each pixel.

ScanM v2.03/v1.1.36.64

Intermediate test version.

ScanM v2.02/v1.1.36.64

  • Bug fix: ETL zooming in to 0.1 caused a range error (fixed).
  • Bug fix: error when importing older versions of ScM files.

ScanM v2.01/v1.1.36.63 (started 2017-05-29)

  • Added the ScanM/Igor version to the Microscope panel to facilitate identification of the currently installed version.

  • ScanM now loads at startup any .ipf in the ...\User Procedures\ScanM\ folder that starts with usr_. This way a user can add functions without having to change ScanM's main .ipf files. For a first application, see below.

  • The user can now add an own function for auto-scaling the image during a scan. In addition, a new GUI element called "Scaler" was added; it can be used in the user-defined auto-scale function. ScanM now checks if a function called usr_AutoScale(...) is defined. If this is not the scale, the built-in auto-scale method is used. If usr_AutoScale(...) is defined (i.e. in the user function file, see above), then it will be called.

    The function must have the following format:
    usr_AutoScale (wFrame, scaler, newMin, newMax), with wFrame containing the current image of the selected recording channel, and scaler the scaling factor set in the new GUI element. The function has to return new values for the limits the colour map will be adjusted to (newMin, newMax). Here is an example implementation suggested by Tom Baden:

      function usr_AutoScale (wFrame, scaler, newMin, newMax)
        WAVE	     wFrame	
        variable   scaler			
        variable   &newMin, &newMax
    
        ImageStats wFrame
        newMin    = V_min
        newMax    = V_avg +V_sdev *scaler
      end
    

    IMPORTANT: Delete all ColorMapping.itx files from ..\WaveMetrics\Igor Pro 6 User Files\ScanM_Settings; they have changed and ScanM will not accept old files.

ScanM v2.00/v1.1.36.63 (started 2017-01-30)

  • ScanM32.dll (v1.1.36.63)

    • Added parameters (offsetZinV, absMaxZinV, absMinZinV, zeroZinV, zoomFactorZ) to ScanMachine structure with respect to the CMD_SET_SCAN_AREA command. These parameters allow for modifying the z axis (AO channel 3) live during a (focus) scan.
    • The CMD_SET_SCAN_AREA parameters rangeXinV, rangeYinV are now re-used to define channel specific limits for the scanner voltages. Before, only general limits (AOMaxInV, AOMinInV) could be defined. They still exist and limit the voltage range, but now they can be set less restrictive (e.g. xy should be -4..4 V, whereas z with the ETL needs 0..5 V).
  • ScanM.XOP was adapted to match the changes in ScanM32.dll.

  • Now both DLLs can be compiled using Microscoft's Visual C++ Studio 2015.

  • Removing unnecessary scan modes and modularizing the code for arbitrary trajectory scans such that users can easily define new types of scans. Instructions to do so will follow soon.

  • IMPORTANT: Changes to existing ScanM installations (in addition to replacing the code):

    • In ScM_USER_DEFINITIONS.ipf, add below the line:

        constant   SCM_indexLensZ            = 3       
      

      the following new definitions:

      constant   SCM_maxRangeScannerX_V    = 8.0        
      constant   SCM_maxRangeScannerY_V    = 8.0        
      constant   SCM_MinETL_V              = 0.0
      constant   SCM_MaxETL_V              = 5.0
      
    • The following changes are only necessary if you want to keep older scan configuration files; if you replace your configuration files by the current ones in the repository, no changes are nescessary.

      Replace the following line at the beginning of each existing configuration file:

        cp.sConfPath = sName // Data folder name (don't change) 
      

      by the following line:

      ScM_initConfigParamsStruct(cp, sName)	
      
    • At the end of each existing configuration file delete the following line (if it exists):

        cp.usesBlanking      = 1      // 1=use generate blanking signal
      

      ... and add the following two lines:

      cp.noAOCh2_Blanking  = 0     // 0=enable 1=disable AO channel #2 (used the blanking signal)
      cp.noAOCh3_Z         = 1     // 0=enable 1=disable AO channel #3 (used for the ETL)
      
  • The additional scan parameters (i.e. for scans that involve the z-axis) as well as the setting of the ETL (zoom, offset, zero level) are now saved in the ScM header file.

  • ScM_FileIO.ipf now can handle the new parameters. In addition, if now reads out the file GUID as and saves it in the string parameters as a 32-character hex string (=4 uint32 values).


Release notes for "ScanM32.dll"

For versions before January 2017. For newer versions, see general release notes above.

0.0.36.62

  • Added parameter invertPixels to the Scan structure and InitializeScanMachine (CMD_INITIALIZE) to allow for inverting the pixel values (currently only for PIXELTYPE_AI3216)
  • ScanM.XOP was adapted accordingly.

0.0.36.61

  • Current stable version

  • Fixed bug in configuration that caused setting different pixel clocks in the two-card configuration when the digital IO card (e.g. 6363) is faster than the 6110 card.

  • Issue #1 - Does not allow scans that require the stimulus buffer to be transferred to the hardware very quickly (e.g. 64x16 w/ 2ms/line) when using the PCIe-6363 instead of the standard PCIe-6259. This is a problem, because NI plans to replace the 6259 model by the 6363 cards. Was already an issue in earlier versions of the DLL, but was not noticed because the 6363 was not yet productively used.

    EDIT: This problem seems to be related with swapping very short scan stimulus buffers on the 6363, because pixel acquisition seems to continue, while the scanners stop. As a work-around and also needed for even faster scans, the Igor code needs to be rewritten such that one scan stimulus buffer can serve (contain) multiple frames (and pixel buffers).

0.0.36.60

  • Current stable version

0.0.20.3

  • issue #1 - in recording mode, when user aborts, a number of frames/pixelbuffers in the smp files are empty (not yet looked at in detail, approx. 10%). Files apear to be complete (= requested number of frames/pixel buffers when ScanM is allowed to record the full sequence.
  • issue #2 - design flaw: the last SetFocusScan-settings need to be applied, also in record mode (even if further zooming, rotating etc. is not allowed).
  • issue #3 - sometimes DLL error messages pop up after successful (?) recordings (pictures of message boxes available).
  • issue #4 - it is not possible to start a recording/focus scan after one has finished without reloading the configuration.

Release notes for Igor/ScanM

For versions before January 2017. For newer versions, see general release notes above.

v38.00.0 (started 2016-01-01)

  • Integrated the code from all three setups, including a temporary fix to run line scans, the changes to use XYZ-scans using an electrical lens (not finished), additional parameters in the ScanM header files and many more small changes.

v36.61.1 (started 2014-08-18)

  • Under Win7-64 bit, pixel data retrieval (via GetPixelData) appears to be not as responsive as under WinXP-32 bit. The reasons are unclear, but the problem seems to be the ScanM-DLL. This issue does not affect the reliability of the data acquisition; it only affects user experience. To solve this problem, the background task that updates the frame view of the Igor GUI was rewritten. It requests smaller pixel buffers and adapts to the update rate of the ScanM GUI: If Igor starts lacking behind, it jumps to the most current pixel block. This measure resulted in a much smoother GUI behavior. A new menu entry (Display always full frames) allows the user to decide if frames are displayed when they are complete or if parts of the frame should be updated as data comes in.

  • Continued to work on a real thread based update of the ScanM GUI; to this end, the ScanM.XOP was updated (now 20140818).

    Changes to the ScanM.XOP:

    • ScMSendCommandEx() as a threadsafe version of ScMSendCommand (), same functionality
    • ScMGetImageDataEx() as threadsafe version of ScMGetImageData(), same functionality
    • ScMGetNextImageDataChunk(), a function that waits for the next pixel data block before it returns (The latter works but only for a limited number of buffers; then ScanM crashes. Not sure what level causes this problem, but it is not at the Igor level. Either in the DLL or in the XOP)

    Igor part of ScanM:

    • Sc_Send_CmdGetPixelPos() implemented

    In principle, a thread-based version is possible and working. Before continuing here, DLL and XOP need to be checked for problems concerning the above mentioned instability.

  • Issue #1: When taking Z stacks, the first few images are not displayed in the Igor GUI. Now when taking a z-stack, the number of pixel buffers per frame is set to one. The original number of pixel buffers per frame is restored when leaving the z stack mode.

  • Continued with online-ROI analysis. Added possibility to average trials according to a sequence of stimulus conditions, either as a direct list (e.g. "0,1,2,3") or as an Igor Text Wave (1D numeric wave; wave name must be identical to file name). In both cases, the different stimuli are to be defined in the defined in the configuration file (see above).

v36.60.5 (started 2014-05-08)

  • Two-channel overlay feature added (see features below). Now remembers its position; in addition to "alpha" for blending and "gamma" now also a factor ("gain") can be adjusted for each of the two overlaid channels.

v36.60.4 (started 2013-03-07)

  • ScM.XOP recompiled with Visual C++ 2010 and Wavemetrics XOP Kit 6 to enable ScanM to run on 64bit Windows. So far, Windows 7 64bit is being tested.
  • Small adaptations (bug fixes) of the Igor code as consequence of the stricter compiler policies in Igor version 6.30.
  • Changed pixel data retrieval strategy from getting the data blocks sequentially to always requesting the most recent block. Should make the GUI more responsive.

v36.02 (started 2012-10-13)

  • Implemented and tested acquiring multiples frames (up to 5) per z-level when recording z-stacks. Changed .smp-file importer to account for this and do the averaging when loading the stacks (the changes in the loader are still beta).

    New parameter in the .smh-file:

      UINT32,NFrPerStep=1 // := number of frames per z-step
    
  • Added more parameters to .smh file header:

       REAL32,XOffset_V=-0.3
       REAL32,YOffset_V=0.05
    

    These report the scanner offset voltages during a recording

  • "Autoscale y axis" button added to ROI data window.

  • FocusZoom_LUT parameter added to "ScanM_Settings.txt"; zoom levels are now defined by list. (FocusZoom_WheelClick is depreciated)

  • Bug fix: Last zoom factor is not anymore stored in "ScanM_Settings.txt".

  • Bug fix: AI channel selection was not always considered when changing configurations.

  • Generated more configuration files; in particular to make sure that line duration is exactly 2 ms; this was already the case for 64(80)x and 32(40)x configurations, but not for 128(16x)x configurations. By using pixel durations of 12.5 us and oversampling factors of 10 (needs to be tested on life tissue!), also with 128(160)x configuration lines are 2.000 ms.

    When loading a configuration with pixel duration fractions in the 50 ns range, ScanM returns an error and indicates that AO and AI run on different sample clocks (e.g. 6.25 us -> 6.2 us for AI and 6.25 us for AO). For unknown reasons, configurations with lines of e.g. 100 pixels do not work for every combination of AI channels; the error dialog generated by the ScanM DLL is rather mysterious ("Chosen pixel buffer size leads to an oversized map size of 70 Megabytes! A multiple of 65536 should be devisible by the sum of pixel buffer sizes without reminder!")

v36.00

  • Z-stacks implemented (averaging each plane is still missing)
  • Online ROI analysis implemented (still buggy).
  • Configuration files use now a much simpler format.
  • Color maps from CfNT can be used.

v22d

  • Major change: Complete program structure altered; no code in "Procedure" anymore (now in "ScM_Main.ipf") and changed to a package implementation (see also installation notes). The advantage are:
    1. that ScanM always starts in a defined state because all structures are recreated anew,
    2. instead of an specific experiment, Igor is started and offers a menu item to load ScanM
    3. changes in the source code can be easier made
  • GUI: Controls for user defined color maps added (feature not yet implemented)
  • Logic and new scan properties (scanType: timelapsed, zSTack, ...) added for z-stacks. Needs to be completed.

v21e

  • GUI: Some corrections and additions to the GUI logic (e.g. either focus or z-stack scan allowed; new tab in configuration panel, for z-stack parameters, etc)
  • Color mapping is automatically saved/loaded
  • Started to implement the z-stack logic (at this point to be able to test the ScanM DLL pause function; the interface to the Sutter MP still needs to be adapted to Igor ...)
  • Alternate scan version (switchable via "#define isUseMultiThread" in Procedures) that uses an additional Igor thread and the new CMD_GET_NEXT_IMAGE_CHUNK command (waits in thread for new pixel data). The Igor side seems to work (at least as dummy, w/o NI hardware), but there is currently no data received from the ScanM DLL ...

v21a-d

  • GUI: Some corrections of the GUI logic (with respect to color mapping, ...); indicator for USB camera added but not yet activated. Cleaned up menus. Disabled interactive scan area controls during recording, also "zero" button. Added buttons for loading and saving the color mapping to arbitrarily named files.

  • Automatically save/load stimulus configuration settings (e.g. color mapping, ...)

  • Adapted parameters for DLL-calls:

    • CMD_SET_SCAN_AREA: values for range and offsets are now in V (instead of mV), the rotation angle is now of a float and gives the angle in |deg| (instead of 1/100 |deg|).

    • CMD_SET_SCAN_CONFIG: all durations (targetedStimDuration, targetedPixelDuration) are now of the type float and given in us; this allows to tune the line and frame lengths more precisely.

  • Started to reorganize the definition of configurations: Simplified, working towards a text file-based approach of defining stimuli ...

  • Bug fix: XY-scan stimulus function did not define the scanner path for the last retrace, now does such that frames should be smoothly connected.

v20b-e

  • Import routines for (still separate) .smp (pixel data) and .smh (header) files updated, rudimentary reader demo written.
  • Some minor changes and corrections.

v20a

  • Allow to adapt the directions of the x and y scan axis (mirroring), controlled by constants (SCM_XYScan_doMirrorX, etc) in ScM_USER_DEFINITIONS.ipf
  • Improved live-view for line and trajectory scans
  • Improved communication with the Arduino (via R4I) by allowing to send a command several times in case of errors. Does not solve the problem completely; possible an issue with the speed (still 115200 baud), but at least laser shutter control seems to be now reliable.

v19

  • Improved management of color mapping
  • Cross-hair for multiple channels implemented
  • Preliminary USB-camera support added