antonhibl
commented
5 months ago After a review of the MexHrscPds3NaifSpiceDriver implementation and its handling of the HRSC's variable line exposure times, it appears that the current operation aligns with the expected functionality of the hardware. The line_scan_rate method already accommodates the variable exposure durations inherent to the Mex HRSC imaging process, correctly parsing and utilizing the exposure times from the binary data for each line.
This method's designed so that it negates the need for a more usual line_exposure_duration property, which would otherwise return a single, static value, not suitable for our use case where each line can have a different exposure duration, like mentioned in the issue. Given this, the existing implementation in MexHrscPds3NaifSpiceDriver does seem to be functioning as intended, handling the variability in line exposure times directly through its own line_scan_rate property.
As such, no changes are necessary to address the issue of line exposure duration handling for the Mex HRSC PDS3 data within the current driver framework. I will try to ensure that this behavior is more clearly documented to avoid any confusion in the future. I am closing this issue as the current functionality meets the requirements for handling variable line exposure times in Mex HRSC data.
The new MexHrscPds3NaifSpiceDriver class re-implements LineScanner::line_scan_rate() for variable line exposure durations being pulled from the binary data, but Pds3Label::line_exposure_duration() is still expecting to pull a single value from the label (where it does not exist). In MexHrscPds3NaifSpiceDriver, the line_exposure_duration was re-implemented to return nothing, but it seems like (barring this value is not needed for other calculations) that this method simply should not exist for variable line exposure scanners?