Dear OFM developers,
I know this topic has come up before (e.g. https://openflexure.discourse.group/t/stream-resolution-options/713. However, it would be great if somebody could check if 1640x1232 realtime streaming or local saving would be possible at least with a raspberry pi 4. With a 100x/1.3 objective, 832x624 pixels is a substantial undersampling, and optical resolution is lost. Full HiRes (3280x2464) however would be a massive oversampling, so not really a need for that. But 1640x1232 seems to be close enough to the sweet spot
Also, just for personal interest , could somebody please enlighten me about the reasons to downscale to 832x624, which is just marginally larger than 1/4 of the full resolution, and so probably not optimal in terms of computing resources?
Once again: Thanks for your great design and brilliant work, and esp. to @JohemianKnapsody for his support,
yet another Michael
The server software is in the middle of a reconfiguration that includes moving to the picamera2 library. It does not look as though the Forum topic that you linked to was ever made into an Issue on Gitlab as suggested. With the server re-write, the question is now not so much about dealing with the current question, but thinking about how this is implemented in teh new server and what functions like this users are looking for.
is there an official way of proposing functions for the upcoming server software? Should I open an issue on Gitlab, or have an open discussion in the forum?
Here my two cents on new functions:
- as already stated, a simple way of working directly with higher resolutions (instead of storing them locally and downloading them later) would be great
- support for Raspi HQ and GS camera would be brilliant (even though this would also require some rework with the camera module and the tube lens)
- the HQ camera seems to come with an integrated method for focus measurement, maybe that would be a more precise option for a fast autofocus than measuring JPG size in the MJPEG stream?
- a little bit special, but useful for resolution enthusiasts like me Would it be technically possible to extract only the blue channel from raw/Bayer data directly within the Pi at a decent speed? For monochrome material this would be the best option to receive high optical resolution, and at the same time reduce data load.
- extending the “navigate” panel with a second, much larger step size for z/focus would improve manual focusing, simulating the coarse and fine focus drive of a conventional microscope. Maybe when starting a z-move by mouse wheel, pageup/down keys or button-click, make it 10x the steps if e.g. the SHIFT key is pressed simultaneously?
More ideas will probably follow, as I am still getting to know the OFM.
Either or both. An issue on Gitlab with a link to a Forum thread is common.
There are actually several different types of thing in your suggestions.
The last one is the web app user interface, which is very easy to change when changes are agreed. There is already an issue on more buttons in the web app #241.
Camera stream resolution and extracting just blue are deep in the camera control, I know nothing about how hard they might be.
Supporting the other Pi cameras is already in the pipeline, @r.w.bowman is making progress on the software and has the main parts working I believe. The hardware modifications for pi camera module 3 are ready to go. The HQ camera is similarly simple if we crop to the centre of the sensor. This still has plenty of pixels to cover the optical resolution I think. Using all of the bigger sensor is difficult to achieve without a very long optics module (on another thread here - Support for HQ Pi camera).