icr-ctl
commented
2 years ago Makes total sense to capture at the PiTFT native resolution. The only thing that might change that is if in the focus tool we wanted to zoom in (digitally) as we are doing with the preview window in the current dencam.py. But let's not worry about that for now.
I haven't gotten my head fully into the details you go through above but the workaround you've thought of sounds kind of clunky. But I would also say that what I understood was the result of our foray into trying to do variance of the Laplacian without using OpenCV was 1) that there were a lot of compelling reasons to stick with OpenCV (including that the grayscale conversion was faster as you mention) and that we could even use cv.VideoCapture to capture directly from the picamera and 2) that the scope of implementing a focus score feature in the main DenCam code was getting to be more than this feature is currently worth to us.
As we talked about yesterday, I think we should push off trying to integrate this feature into the main DenCam code because of the degree of re-architecting that system that would be required to facilitation that integration but just capture the work you've done on this feature into these two scripts for future use and until we decide to revisit it. So I think we should merge this PR without closing the bigger issue whenever you have resolved the remaining bug you have.
Very glad to hear you are doing testing and catching bugs!
To check: examine_focus_w_grid.py is the faster of the two scripts at this stage, right?
iamgarcia
The reason I marked the PR as a draft is because I caught two bugs while doing further testing. One of them I've already resolved, but I'm still working on the last bug.
I've been capturing images in 640x480 using both OpenCV and PiCamera due to the PiTFT resolution as well as performance concerns. For the OpenCV script, I've had significant performance and color issues capturing at 1080 and then resizing it down so I can display it on the PiTFT. As for PiCamera, ideally, it would be best to move from using tkinter's update() method to using the after() method because update forces the updating of the display. However, this would involve figuring out how to get around the for loop of the current capture_continuous method. Also, update can lead to unpredictable behavior or looping. After solving that issue, there remains 2 performance concerns: how PiCamera is capturing images and the color conversion using numpy.dot. As we discussed, I could import OpenCV's color conversion method. However, would that defeat the purpose of having a SciPy version of the tool? As for PiCamera's capturing of images, capturing a single image using the capture method and storing the data in buffer is possible but performance is impacted when capturing at 1080p. A better approach would be to use a capture method that utilizes the video port parameter since it would capture images from the video port (which tend to have a grainy appearance), but as far as I know, capture_continuous is the only method that is suitable for this task. Having said that, to use this method, you need to use a for loop. This kind of defeats the purpose of the after method since it won't be called because the capture_continuous method is infinite. Though, a work around would be to just run through the loop once and break from it, then use the after method and repeat the process again. What do you think?