Version
- Baseline is the DART Updates branch of the blessed code repository on Github.
- See Github for details on code modifications.
Quasi SIS
Extract information from the SIS or derived from common practices. It is logged here so we have it in a single place and can define specific pieces.
DRACO
- Source Image
- FITS
- Byte type MSB
- 16 bit - integer
- ? Unsigned
- Size 1024 x 1024 (max -- will use windows)
- ? Image time definition: ACQTM_ET, COR_UTC
- ? No data: 0
- ? Testing data range is (0-255) 8-bit unsigned --- Is it 0, 1 or a bias?
- ? Testing data: min: -32768, max: 255
- Processing
- ? All done with short integer space
Remove Flatfield -- Flatfiel is _. Stored
- Filename prefix D
Filename core: ACQTM_ET -> ET0
- Filename special ID:
- ? USECLK
- (what is G)
- Exposure Time: ACQTMSUB
- Saved DAT
- Byte type: MSB
- Unsigned 16 bit integer
- Stretch: None -- direct pass through
- No data: 0
- Threshold: 5
- Spacecraft: 1
- Camera: 1
- ? Flags for make_sumfiles:
LICIACube LICA
- Source Image
- FITS
- Byte type: MSB
- 16 bit - integer
- ? Unsigned
- Size 2048 x 2048 (max -- windowing ?)
- ? Image time definition: IMG_TIME, IMG_UTC
- ? No data: 0
- ? Testing data range is (0-255) 8-bit unsigned --- Is it 0, 1 or a bias?
- ? Testing data: min: -32768, max: 255
- Binning options
- Processing
- ? All done with short integer space
Remove Flatfield -- Flatfiel is _. Stored
- Filename prefix L
Filename core: IMG_UTC -> ET0
- Filename special ID:
- What do we do with binning
- ? USECLK
- Saved DAT
- Byte type: MSB
- Unsigned 16 bit integer
- Stretch: None -- direct pass through
- No data: 0
- Threshold: 5
- Spacecraft: 2
- Camera: 2 and 3
- ? Flags for make_sumfiles:
Cameras
- DRACO - NAC imager on DART
- LEIA - higher-res, panchromatic camera on LICIACube
- LUKE - low-res, color camera on LICIACube
Issues
- Need processFits to correctly populate make_sumfiles.in with the different spacecraft numbers and camera numbers.
- Per email exchanges 3/11/21, Olivier is making a custom make_sumfiles.f for DART to prevent OREx-specific stuff in make_sumfiles from biting us. He will be using a scheme where each spacecraft has a unique camera. So, spacecraft 1 (DART) will have camera #1 (DRACO). Spacecraft 2 (LICIA) will have cameras #2 (LEIA) and #3 (LUKE).
- Need to standardize whether PROCESS_FITS_DART_TEST and PROCESS_FITS_LICIACube_TEST live in LITHOSPHERE or in Missions.
- Notes on testing Olivier's code from Github. I can get Display to work if I compile and link to Olivier's COMMON.a. I can run the executable Display Olivier compiled and get a nice image out. But, if I build COMMON.a myself and recompile Display, then Display doesn't work correctly. So, something going on in building COMMON.a?
Table of Spacecraft and Cameras
Name |
S/C |
Number |
|
DART |
1 |
DRACO |
1 |
LICIA |
2 |
LEIA |
2 |
LICIA |
2 |
LUKE |
3 |
Process for making updates to SPC code
1. Create a new branch off of DART-Updates (https://github.com/StereoPhotoClinometry/Blessed/tree/DART-Updates). On the Desktop app, check that "Current Repository" is "Blessed". Select the arrow next to "Current branch". Then select "New Branch". Give the branch a name, and make sure that "Create branch based on..." is the branch you wish to work off. The name should include the objective of the branch (e.g., make_tilefile_dense if you are editing make_tilefile). Including the name of the person making the branch can also be helpful (e.g, terikEqualize). Or, go all out and add the date as well (e.g., terikLimber12March2021). Then "Publish Branch" when you are ready for others to see it.
2. Make your changes on that branch. If they are simple, do it in the online Git interface for ease of tracking. If you make the changes on your local machine, you will need to "push origin" for them to get to everyone else. The "push origin" step is crucial. It's also crucial that changes get made on the branch you are editing, not to a different branch.
3. Once other folks have tested the changes and agree they accomplish the intended objective, submit a pull request to merge the working branch back to DART Updates.
4. Eric reviews the pull request and merges the changes to DART-Updates if they look good or else requests changes if he sees issues.
To be continued... Terik plans to add screenshots that show how to do this.
Process for getting the most recent SPC code
1. Choose branch. 2. In online Github, choose the green "Code" and clone the desired branch do your machine or "Download ZIP".
To be continued... Terik plans to add screenshots that show how to do this. If we can all get on the same page about how to change code and access updated code, it will help.
If we have an agreed upon procedure, it will help things.
Terik wish list
- Display to work without requiring a change to INIT_LITHOS.
- Everyone use the same compile scripts. Not precious about what they are, but want to remove this as a variable. Remove all other compile scripts from the DART-Updates branch so that the only option is THE option. Will probably mean people agreeing on particular paths.
- All code changes made on branches off of DART-Updates, preference for small changes that get merged often, vs. big changes that don't get merged often. Push/pull origin on a regular basis so we all stay synced.
- Decide where PROCESSS_FITS* live--Olivier has them in LITHOSPHERE. Eric wants them in Missions. Terik thinks the latter makes more sense.
- Decide whether it makes sense to rename a DART-specific make_sumfiles to make_sumfiles_dart. If the latter move it to Missions?
- Comments on code are updated when code is edited and reflect the current contents, rather than leftovers from the past.