[INSTRM-2148] Missing spots in MCS image Created: 18/Jan/24  Updated: 07/Feb/24

Status: In Progress
Project: Instrument control development
Component/s: ics_mcsActor
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Normal
Reporter: chyan Assignee: karr
Resolution: Unresolved Votes: 0
Labels: EngRun
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File centroids.png     PNG File image (1).png     PNG File Screenshot 2024-01-18 at 11.19.47 AM.png    
Issue Links:
Blocks
is blocked by INSTRM-2156 Analyze MCS image in Dec 2023 to see ... Open

 Description   

During the MCS re-alignment work, we found some cobras are missing in the obslog. By looking at the image, there are spots but we failed to detect them. We should try to recover those spots before Subaru fix this from hardware side.



 Comments   
Comment by yuki.moritani [ 24/Jan/24 ]

Note: these faint fibers were sometimes detected in December 2023 (e.g., visit=104112)

Comment by karr [ 24/Jan/24 ]

It looks like one of the modules is much fainter than the rest, with typical peak values 1/4 that of typical spots in the rest of the image. 

During observations, you can manually compensate for this by manually setting the thresholds for spot detection to a lower value using the setCentroidParams command.   Note, however that setting the threshold too close to the noise level will slow down the routine, and may lead to false spot detections. 

Comment by karr [ 02/Feb/24 ]

It turns out this is a different problem; detecting and adjusting for things like one module becoming much fainter during operation. 

After discussion with Shiang-Yu, we propose a test sequence that can be run at the beginning of the night. The cobras are parked at home, a short exposure is taken (ie, the exposure time used at the beginning of a sequence), and the number of spots counted and matched. If fewer than the expected spots are found, the thresholds of the spot detection will be changed until they are, within reasonable values, and a message produced. 

If reasonable alterations to the threshold do not work (ie, they can't be detected, or it pushes the threshold so low that we're getting false detections), a different alert will be raised, and there should then be an option to temporarily mark the undetectable cobras as un-illuminated for the remainder of the night.  

We need to think about how re-setting the actor affects this, as the thresholds will reset to default values after restarting the MCS actor. 

Comment by yuki.moritani [ 02/Feb/24 ]

Are you proposing to have a function to calculate (search for) centroid parameters for given sets of MCS images, rather than to take images changing the parameters? (I think yes, as we don't need to take new images every time.) Also, I feel we should use the number of spots identified as Cobra/FF (because the number of spot can be larger if MCS get noise, and unsolved issue (e.g., INSTRM-2157).)

Also, is that mean you couldn't find a good solution to detect both faint and bright fibers? At some case you detected all fibers, but some not... and you didn't find difference..? If that is the case, I'm not sure how searching parameter will work..

 

Comment by karr [ 02/Feb/24 ]

If we're just adjusting the threshold, we can do the calculation on the same image. If the cobras are at home, we will know they aren't behind a dot (which is the other reason you might not see a spot), and can filter for spurious points. 

Whether we can find a good solution is going to depend on exactly how faint the spots are; in some cases, lowering the threshold will work, but if they are at or below the noise level, lowering the threshold isn't going to help. So if you want a general routine to detect and adjust for situations like this, it needs to be flexible. 

 

Comment by karr [ 07/Feb/24 ]

For these data, it looks like a fairly modest reduction of the threshold, combined with adjusting the minimum number of acceptable spots for a detection, will detect all the sources in the faint regions. 

I need to check the updated parameters for robustness with other data sets, but it looks like a fairly simple fix. 

Generated at Sat Feb 10 16:43:29 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.