Add a Tool to acquire images from camera accessed over an HTTP route

[ethanjli]

Changes

Adds:

• A new HTTPCamera tool in science_jubilee/tools/HTTPCamera.py whose Python API is meant to closely follow the Camera tool's Python API but which acquires images from an HTTP route instead of using picamera

Motivation/Context

In the POSE Workshop on 2024-04-27, a mini-project to use the Jubilee as an object scanner found that image acquisition was really slow due to how picamera works. As a quick-and-dirty workaround, I deployed https://github.com/jacksonliam/mjpg-streamer onto the Jubilee's Raspberry Pi computer and added the HTTPCamera tool to acquire images via HTTP from mjpg-streamer rather than acquiring them from picamera. This PR contributes my new HTTPCamera tool, since it sounded like there might be some interest in the tool itself, and since I volunteered to be a "guinea pig" for the process of submitting new tools as an external contributor which could lead to new docs or templates to help people share their tools.

Alternatives

Having inspected the Camera source code, I think a potential cause for Camera being slow to acquire images could be that the get_frame method is instantiating the picamera.Picamera class each time the get_frame method is called - so the camera is doing re-initialization and warmup every time get_frame is called. My intuition is that if you just instantiate picamera.Picamera once - in the Camera class's constructor - and then reuse that instance for every get_frame method call, you may be able to acquire images much more quickly. I can try to make this change in a new PR, but (as mentioned below in the PR checklist) I'm not sure if I'll be able to test it out in the science_jubilee repo. If it works, that would be a more direct solution to the issue of slow image acquisitions.

Unresolved Questions

Because this PR was made from hackathon-quality code (i.e. it took some shortcuts to make things work quickly), I don't think it's ready to change the status of this PR from "draft" to "ready for review" until we address some questions:

• Currently the URL of the image to acquire is hard-coded in the get_frame method as http://localhost:8080/?action=snapshot. Should we instead parameterize it as a keyword argument (e.g. route or url), e.g. of the get_frame method or the class constructor (and if so, which one should take the keyword argument? i.e. is it better to make a get_frame which is not exactly interchangeable with Camera's get_frame method, or is it better to make a constructor which is not exactly interchangeable with Camera's constructor)?
• I made this tool by copy-pasting the code from the Camera tool. Is this acceptable, or would it be better to instead define this tool as a wrapper around the Camera tool, e.g. by defining HTTPCamera either as a subclass of Camera or as an object which holds an internal Camera instance but provides a Python API surface (e.g. without a video_stream method) or different in certain ways (e.g. inability to explicitly specify image resolution in any image_wells and get_well_image methods) that would make HTTPCamera non-interchangeable with Camera?
• The PR template asks me to indicate the number of the issue which this PR resolves. Is it fine for me (@ethanjli) to open this PR without an attached issue, or should I make an issue? If the latter, should the issue be about Camera being slow to acquire images (which will be solved without this tool if/when the project migrates from picamera to picamera2, or maybe just by instantiating picamera.Picamera in the Camera tool's constructor rather than in every get_frame method), or about the lack of a way to acquire images from arbitrary picamera-incompatible cameras or simulated image sources (which might not [yet] be a real problem in need of a solution)?

PR Checklist

• (for the PR reviewer) Address unresolved questions
• (for @ethanjli) Make changes (as needed) to implement any decisions made about the unresolved questions listed above
• (for @ethanjli) Review any existing docs about how to document a new tool, and add any required docs for the tool
• (for the PR reviewer and/or @ethanjli) Depending on what docs already exist: identify/prioritize documentation work for @ethanjli to do in follow-up PRs, if any docs (e.g. example repos or example code or tutorials or how-to guides or references or explanations) or PR templates (e.g. with a checklist including any items specific to contributing a new tool) need to be added about what to include in a PR to contribute a new tool
• (for @ethanjli) See if I can test a potential performance optimization (described above in the "Alternatives" section) to the Camera class even though I don't have access to Jubilee hardware.
• (for @ethanjli) Handle any merge conflicts with PyScaffold migration: error-free installation on Windows/Linux for Py 3.8+ and .md instead of .rst  #87 either in this PR or in PyScaffold migration: error-free installation on Windows/Linux for Py 3.8+ and .md instead of .rst  #87, depending on which PR gets merged first

[brendenpelkie]

This looks great Ethan! This is similar to the poorly named WebCamera tool, which does essentially the same thing. I like that yours doesn't get openCV involved, which will reduce install complexities for the package.

As you allude to, we have too many camera tools and there is no reason to have identical code duplicated. I opened #94 to consolidate these tools into one camera.