Your fine dedication to CHDK is notable and much appreciated. That's why this entire package is so good, but understandably, is still under development. I think that unless there are obvious gross bugs like the one you addressed with A/R which from the sky-view needed a 2-stage resolution, then I feel addressing more refined areas in a snap of a finger is not often the best approach anyway. On the other hand, discussing these seemingly silly issues however sheds light on what is possible for me, gives you a better understanding of my requirements, and hopefully implants some thought seeds for you if we can meet on common ground. Then a good prudent approach can be developed that can better suit your priority schedule, and naturally your judgment of a new or enhanced feature fit in the global requirements.
Quote "So is the quality of the viewport image critical ?"
Yes it is, very critical. Depth of field is measured in units of microns. RemoteCapture is just on the positive edge of the border of being acceptable. From the last comparison image, the result that came out yesterday is stunning compared to what it was just a few days ago, but still is just on the negative edge of being acceptable. Thus I am primarily interested in three functions: RAW image, liveview, and the ability to operate the camera in manual mode remotely (setting exposure profiles, Tv, Ev, digital zoom, and shooting -- essentially a mix of ptpCamGUI and CHDKPTP, for the SX110). My instrument currently uses an S50 CCD, but that camera has both liveview and RAW capability transfer with RemoteCapture. The SX110 however does have the liveview but does not have RAW out-of-box. That's where your CHDK comes in.
Quote "If so, using a device with a 216 line output is probably not a good choice."
This is a good point. Andor makes scientific cameras that could be used in my application with 640x480 liveview at 30 fps, but they are all monochrome, among several other technical drawbacks that make them unsuitable for my application. Hence commercial scientific cameras cannot be used. I designed this instrument to be very compact and flyable, and therefore it relies on small CCDs, ie 1/2.5" to 1/2" range, and those, complete with readout and data transfer electronics that I don't have to worry about, are only available in small consumer cameras. For a prototype instrument that is intended to validate basic functionality and scientific objectives, that's good enough.
Quote "What sort of instrument is this ?"
It is a microimager, something like MAHLI on MSL, but much more sophisticated. Because I have a publication pending, that is all I can say in a forum. If we chat privately, I can tell you more.
Quote "If you are going to scale it yourself, you might as well take chdkptp scaling out of the equation completely"
I did the scaling in the center panel to test a simple hypothesis and demonstrate the results to you (and to me too). The final objective would be for the liveview to provide a crisp image, not to take CHDKPTP out.
Quote "Start with the aspect correct off, viewport 1:1 (720x216) image, aspect correct by scaling it to something large, e.g. 1440x1080 and then scale it back down to 360x270."
That's a good idea ... I have a tool that does Lanczos interpolation and will try it, but again, that would be a concept test and is not meant to replace chdkptp.
Quote. "Canon image processing pipeline certainly has the capability to apply sharpening to still jpegs, so it wouldn't be a surprise if they applied it remote capture too."
Thank you for this insight, and that is more probable than a side-effect of JPEG artifacts. I agree.
Quote "It's also possible the the YUV/RGB conversion isn't optimal."
It is strange that Canon chose this archaic TV format. I really wonder why // perhaps because their cameras support video // speculating. It is amazing to me how you managed to dig that out. Nonetheless, could something in your routines related to the conversion have an impact on image quality, and give clarity a little boost?
Thank you for your help.
