[INSTRM-1336] Always write RESET_$N HDUs. Created: 05/Aug/21 Updated: 02/Mar/22 Resolved: 02/Mar/22 |
|
Status: | Done |
Project: | Instrument control development |
Component/s: | ics_hxActor |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Task | Priority: | Normal |
Reporter: | cloomis | Assignee: | cloomis |
Resolution: | Done | Votes: | 0 |
Labels: | SPS | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Issue Links: |
|
||||||||||||
Story Points: | 3 | ||||||||||||
Sprint: | SM1PD-2021 A 14, SM1PD-2021 A 15, SM1PD-2022 B |
Description |
The implementation of We almost certainly want to save the reset frame(s), so start always doing that. Basically, there will be W_H4NRST HDUs before the first data HDU. Named RESET_$N, but that is incidental. While at it, add a W_H4FFMT FITS structure version card. |
Comments |
Comment by hassan [ 08/Dec/21 ] |
Craig will add dummy HDUs to address this. |
Comment by cloomis [ 22/Dec/21 ] |
Two, I guess: RESET_DATA and RESET_REF. And drop the $N: I don't see us wanting to run with nreset>1. Of course n4 might change that..... When not saving reset frames, can save a full-sized frame of 0-valued pixels (about 300kB with RICE for each) or save a 1x1 pixel array. The first seems right, if we are aiming to simplify DRP fiddling. |
Comment by cloomis [ 28/Jan/22 ] |
It turns out that it is hard enough to figure out what the reset frame properties that making dummies is not worth the trouble. So I'm doing the work to generate real reset frames. |
Comment by cloomis [ 02/Mar/22 ] |
Merged at 2c76f84, tagged 2.2.0 |