Sorry, I don’t understand what you mean by ‘subframe’ in SGP context, perhaps this is what is used for autofocusing or displayed in quick rendering or something in the UI? Or do you just mean a single capture, as in ‘sub’ that we use to stack overall? In either case, I’m talking about a single capture from a full frame sensor - the data captured is HUGE. We are talking about reducing a single frame capture, this is possible via ROI and ASP-C reduction of sensor activity by the drivers provided by manf.
ROI is really important imho, you can ‘just crop’ but these full frame image files are HUGE! So you are forced as a user to expend a TON of cabbage ($$) with extra processor, extra ram, HUGE storage volumes to do many many caputre files that you then just crop in processing post stack!! That is crazy! When many many targets the huge field of view of the full frame sensor just isn’t needed, so if you reduce the ROI, you should be able to greatly reduce the file size. Make sense? Thanks Jared for investigating - and yes, I understand with both the ASCOM and I believe in the native drivers from ZWOASI (and I think from QHY and others) they have implemented a back-down capability to reduce the processor utilization down to the APS-C size. It would be SUPER cool if we could actually specify the region of interest to anything we want, and the file size of each capture was reduced in a ratio or something - but even just giving us the ability to knock the field of view down (roi) to the APS-C size would be a HUGELY valuable new feature for us in SGP. I understand CCD pilot and SharpCap and others already support this feature, not sure about NINA but I think they do as well or are working on it. Thank you for investigating!!!