Size: 3351
Comment: Notes on troubleshooting PROCESS_FITS_LICIACube
|
Size: 4241
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 7: | Line 7: |
------- = 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: * Testing data range is (0-255) 8-bit unsigned --- Is it 0, 1 or a bias? * Testing data: min: -32768 * No data: 0 * Threshold: 5 * Processing * All done with short integer space * Remove Flatfield -- Flatfiel is _____. Stored ______ * Saved DAT * Byte type: MSB * Unsigned 16 bit integer * Stretch: None -- direct pass through === LICIACube === * Testing data range is (0-255) 8-bit unsigned --- Is it 0, 1 or a bias? * Testing data: min: -32768 ------- |
|
Line 12: | Line 52: |
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:
- Testing data range is (0-255) 8-bit unsigned --- Is it 0, 1 or a bias?
- Testing data: min: -32768
- No data: 0
- Threshold: 5
- Processing
- All done with short integer space
Remove Flatfield -- Flatfiel is _. Stored
- Saved DAT
- Byte type: MSB
- Unsigned 16 bit integer
- Stretch: None -- direct pass through
LICIACube
- Testing data range is (0-255) 8-bit unsigned --- Is it 0, 1 or a bias?
- Testing data: min: -32768
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