Difference between revisions of "2015 Summer Project Week:Astronomy"
(22 intermediate revisions by the same user not shown) | |||
Line 6: | Line 6: | ||
==Key Investigators== | ==Key Investigators== | ||
*Davide Punzo, Kapteyn Astronomical Institute, University of Groningen, Netherlands | *Davide Punzo, Kapteyn Astronomical Institute, University of Groningen, Netherlands | ||
− | * | + | *Steve Pieper, Isomics |
==Project Description== | ==Project Description== | ||
Line 40: | Line 40: | ||
<div style="width: 27%; float: left; padding-right: 3%;"> | <div style="width: 27%; float: left; padding-right: 3%;"> | ||
<h3>Approach, Plan</h3> | <h3>Approach, Plan</h3> | ||
− | * | + | * discuss the best approaches; |
</div> | </div> | ||
<div style="width: 27%; float: left; padding-right: 3%;"> | <div style="width: 27%; float: left; padding-right: 3%;"> | ||
<h3>Progress: </h3> | <h3>Progress: </h3> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
<h3>outcome from 1st day: coordinates, labels and units. </h3> | <h3>outcome from 1st day: coordinates, labels and units. </h3> | ||
− | *data probe coordinates: factorize getPixelString in the logic of the volumes; | + | *VTK_FITS reader (and writer) and the Slicer AstroVolume module done; |
+ | *data probe coordinates: factorize getPixelString in the logic of the volumes and use the WCSlib in the logic of AstroVolume; | ||
*ruler widget: takes units properly -> OK; | *ruler widget: takes units properly -> OK; | ||
*text on slices view: takes units properly -> OK; | *text on slices view: takes units properly -> OK; | ||
− | *"spacing annotation" (horizontal widget showing the physical spacing): problem, makeScalingRuler method is hardcoded with mm and cm. Moreover we'd like a different design | + | *"spacing annotation" (horizontal widget showing the physical spacing): problem, makeScalingRuler method is hardcoded with mm and cm. Moreover we'd like a different design -> is factoring the class vtkPVScalarBarActor in the logic of the volumes a solution?; |
*units: we have different unit for the third axes and we have also units for flux (pixel intensity), how to handle these?; | *units: we have different unit for the third axes and we have also units for flux (pixel intensity), how to handle these?; | ||
− | |||
− | *question on AstroVolume and wcs: AstroVolume module allocates a vtkMRMLScalarVolumeNode, therefore I am adding the *wcs (it is a struct) in the vtkMRMLAstroVolumeStorageNode. Is this adequate? | + | *question on AstroVolume and wcs: AstroVolume module allocates a vtkMRMLScalarVolumeNode, therefore I am adding the *wcs (it is a struct) in the vtkMRMLAstroVolumeStorageNode. Is this adequate? or it is better to do a vtkMRMLAstroVolumeNode child of vtkMRMLScalarVolumeNode and store the *wcs there (in this case it is not possible to use anymore CLI modules, but allows a better infrastructure)? |
− | or it is better to do a vtkMRMLAstroVolumeNode child of vtkMRMLScalarVolumeNode and store the *wcs there (in this case it is not possible to use anymore CLI modules, but allows a better infrastructure)? | + | |
+ | <h3>outcome from 2nd day: deeper investigation on units module. </h3> | ||
+ | *unitsLogic->AddUnitNode add a MRMLUnitsNode to the Scene, but from an interface point of view in Settings only two quantities are allocated qSlicerUnitsSettingsPanelPrivate::setMRMLScene -> quantities << "length" << "time"; (in principle adding "length1" << "length2" << "length3", should update automatically the interface). | ||
+ | *AstroVolume and wcs: let's do an vtkMRMLAstroVolumeNode and for the moment lose the skill to use CLI modules. In future we can see some tricks in the COMBOBOX to allow the use of them if they will be required from the users. | ||
+ | |||
+ | <h3>outcome from 3rd day: </h3> | ||
+ | *vtkMRMLAstroVolumeNode with *wcs struct integrated in SlicerAstro extension. | ||
+ | *working on modifications to the Units module for adding velocity and intensity quantities. | ||
+ | *Engineering solutions for data probe and slice view annotations hardcoded features will be addressed after the Units module. |
Latest revision as of 16:10, 14 February 2018
Home < 2015 Summer Project Week:AstronomyKey Investigators
- Davide Punzo, Kapteyn Astronomical Institute, University of Groningen, Netherlands
- Steve Pieper, Isomics
Project Description
Upcoming HI (neutral Hydrogen) surveys will deliver large datasets, and automated processing using the full 3-D information (two positional dimensions and one spectral dimension) to find and characterize HI objects is imperative. In this context, visualization is an essential tool for enabling qualitative and quantitative human control on an automated source finding and analysis pipeline. Visual Analytics, the combination of automated data processing and human reasoning, creativity and intuition, supported by interactive visualization, enables flexible and fast interaction with the 3-D data, helping the astronomer to deal with the analysis of complex sources. 3-D visualization, coupled to modeling, provides additional capabilities helping the discovery and analysis of subtle structures in the 3-D domain.
gas component of WEIN069
APERTIF future daily observation
Objective
- proper visualization of astronomical data cubes: using data astronomical data formats, such as FITS (http://en.wikipedia.org/wiki/FITS), and astronomical world coordinates system (WCS);
- generation of flux density profiles, moment maps and position-velocity diagrams linked with the 3-D view;
- enabling interactive smoothing in all three dimensions and multiscale analysis, such as wavelet lifting;
- interactive 3-D selection of HI sources;
- interactive HI data modeling coupled to visualization;
- introduction of the SAMP protocol (Simple Application Messaging Protocol) to enable interoperability with Topcat, and other VO (virtual observatory) tools and catalogs.
Approach, Plan
- discuss the best approaches;
Progress:
outcome from 1st day: coordinates, labels and units.
- VTK_FITS reader (and writer) and the Slicer AstroVolume module done;
- data probe coordinates: factorize getPixelString in the logic of the volumes and use the WCSlib in the logic of AstroVolume;
- ruler widget: takes units properly -> OK;
- text on slices view: takes units properly -> OK;
- "spacing annotation" (horizontal widget showing the physical spacing): problem, makeScalingRuler method is hardcoded with mm and cm. Moreover we'd like a different design -> is factoring the class vtkPVScalarBarActor in the logic of the volumes a solution?;
- units: we have different unit for the third axes and we have also units for flux (pixel intensity), how to handle these?;
- question on AstroVolume and wcs: AstroVolume module allocates a vtkMRMLScalarVolumeNode, therefore I am adding the *wcs (it is a struct) in the vtkMRMLAstroVolumeStorageNode. Is this adequate? or it is better to do a vtkMRMLAstroVolumeNode child of vtkMRMLScalarVolumeNode and store the *wcs there (in this case it is not possible to use anymore CLI modules, but allows a better infrastructure)?
outcome from 2nd day: deeper investigation on units module.
- unitsLogic->AddUnitNode add a MRMLUnitsNode to the Scene, but from an interface point of view in Settings only two quantities are allocated qSlicerUnitsSettingsPanelPrivate::setMRMLScene -> quantities << "length" << "time"; (in principle adding "length1" << "length2" << "length3", should update automatically the interface).
- AstroVolume and wcs: let's do an vtkMRMLAstroVolumeNode and for the moment lose the skill to use CLI modules. In future we can see some tricks in the COMBOBOX to allow the use of them if they will be required from the users.
outcome from 3rd day:
- vtkMRMLAstroVolumeNode with *wcs struct integrated in SlicerAstro extension.
- working on modifications to the Units module for adding velocity and intensity quantities.
- Engineering solutions for data probe and slice view annotations hardcoded features will be addressed after the Units module.