Follow up on dq_init and guide windows

[stscijgbot-rstdms]

Issue RCAL-427 was created on JIRA by Nadia Dencheva:

Attributes used in dqinit do not appear in ramp schema, perhaps they were populated in the files without being present in the schema.

Possible use of gwcs._toindex instead of "int".

"x" vs "y" convention questions.

See comments in #599

[ddavis-stsci]

I think we have INS input this can be closed. Once SDF gets the GW data and starts to create GW data files we can start another ticket if needed. (rcal-427 is also closed)

[stscijgbot-rstdms]

Comment by Nadia Dencheva on JIRA:

Writing some thoughts triggered by the work on flagging the guide window locations.

One of the issues we need to clarify is the "x" and "y" direction on the detectors. To clarify the issue I will call the coordinate frame associated with the original readout of the detectors "dms_detector" and call "sci_detector" the frame associated with the same physical detector but flipped/rotated/oriented so that x increases to the right (i.e. columns) and y (rows) vertically, essentially following the DS9 convention.

For some detectors these two will coincide for some they won't. JWST does this "reorientation" or "unifying" of the orientation in the refpix step. We may need this done earlier, possibly in or before the dq_init step, in order to have a consistent view of the detector, so that the guide window flagging can be done consistently in the dq_init.

We need to discuss this with RTB at some point Tyler Desjardins 

 

[stscijgbot-rstdms]

Comment by Tyler Desjardins on JIRA:

Spoke with Nadia Dencheva and am putting my understanding of the x and y coordinate systems here. Megan Sosey correct me if I've got anything wrong.

To my knowledge, the detectors are read out in the detector coordinate system described in the SIAF document in SOCCER. This has the origin of the (x, y) system located at the corner of the detector adjacent to the fast and slow readout electronics. There are two different detector orientations when looking at the FPA, so there are two different orientations of the coordinates depending on the detector.

During the conversion of SCIENCE data from L0 to L1 data files, SDF will convert the detector coordinate system to the science coordinate system (see also the SIAF document). In the science coordinate system, all detectors have the same (x, y) origin in the bottom-left when the FPA is viewed with WFI07 and WFI16 in the top corners (the smiley face, not the frown). 

Now for guide window data, I believe they are in the FGS coordinate system (this is similar to the science coordinate system, but the y-axis is inverted, and the origin is at the center of the detector). There is no plan to re-orient these, nor is there a plan to process them beyond L1.

[stscijgbot-rstdms]

Comment by Megan Sosey on JIRA:

Tylers recollection is correct. This is also in the DMS Design Doc here: https://innerspace.stsci.edu/display/RDMSDOC/Science+Instrument+Field+of+View+and+Pointing+Knowledge

We discussed using the on-sky orientation early in the mission to make the information consistent for both the pipeline and the downstream users.

https://outerspace.stsci.edu/display/RSEC/Meeting+Notes+-+February+21%2C+2020

 

 

[stscijgbot-rstdms]

Comment by Eddie Schlafly on JIRA:

The context in which this came up in the PR was how to interpret gw_window_xstart and gw_window_xsize keywords.  I am having trouble following the discussion above in that context.  Should the xstart and xsize keywords follow the conventions for x & y for the L1 pixels (which would sound appropriate to me)?  Is the "x" direction the direction that is contiguous in memory in the L1 pixels?

[stscijgbot-rstdms]

Comment by Tyler Desjardins on JIRA:

Ah, good question. If I recall correctly, SDF is going to have to determine the size of the guide window from the packet data, so in theory that can mean what we want it to mean. Megan Sosey do you recall where the guide window position info comes from? Is that from the telemetry, or is that also something SDF has to figure out somehow? I'm sort of a proponent of keeping telemetry info in the form it comes down in...if that's the case, then I would assume it's in FGS coordinates, and then maybe we can have a gw_window_sci_xstart or similar attribute that gives the translation to the science frame.

[stscijgbot-rstdms]

Comment by Nadia Dencheva on JIRA:

David Davis Is everything mentioned in this ticket completed? Can we close the ticket?