KISS Viewer: Kentucky's Interchangeable-lens Small Sensor Camera in a Mini Viewer

KISS Viewer is Kentucky's Interchangeable lens Small Sensor camera in a mini Viewer. The basic shape suggests the classic look of a Tower Optical Binocular Viewer, and the unit has a pair of viewing holes that can be used for approximate aiming, but the unit is actually a mount for an AI Thinker ESP32-CAM camera to be used with an adapted lens. The native lens is removed from the OV2640 camera module included in the ESP32-CAM, and the KISS Viewer instead allows use of any manual lens in Sony E/FE mount or adaptable to that mount. The OV2640's 2MP sensor is quite small, thus yielding an approximately 9.7X crop compared to a full-frame sensor, so cheap old lenses designed for full-frame cameras yield extreme telephoto captures. I've tested it with a wide variety of lenses, including the 35mm f/1.4, 55mm f/1.8, 135mm f/2.8, and 300mm f/5.6 lenses shown later in this Instructable. The images are delivered to your WWW browser wirelessly via 2.4GHz 802.11, and the HTML page offers a wide variety of still and video capture controls.

KISS Viewer looks like a 3D-printable model of a Tower Optical Viewer. It's not. I designed it by first looking at lots of photos of Tower Optical Viewers, searching for models (there are some, not free), then asking several AIs to create designs. In the end, I basically synthesized my own design almost from scratch in OpenSCAD. My design is much shorter than a scale model would be and the foot step rings are taller. Except for the basic shape of the fork and the area around the view holes, everything has been replaced with my own design elements that are more appropriate to the task. Still, it reminds you of one of those viewers, doesn't it? ;-)

Aside from nostalgia, this shape is useful because a tilting fork is basically what you need for aiming the lens. The catch is, aiming this is incredibly touchy with some lenses, and for that you can use the viewing holes. There are no optical elements in the viewing holes, and you're not going to be able to look through both holes at once for binocular vision, but either hole acts as a pretty good sight for aiming whatever lens you're using. The real viewers rotate in the middle, but this one is easily rotated as a whole, and that makes it stronger than if the post contained a pivot. Strength and balance are both major concerns here, and this design scores much better on both metrics than a true model of a Tower Optical Viewer would.

Note that KISS Viewer is basically a rethink of KISS-E: https://www.instructables.com/KISS-E-Kentuckys-Interchangeable-lens-Small-Sensor/. Although that was originally built in 2021, we have now updated the materials on it and posted everything for people to build their own. Your decision is which version is better for you -- and I suspect your answer will be KISS Viewer because it makes the 9.7X crop a lot easier to use to your advantage than KISS-E does.

Obviously, there's a lot to 3D print in this design. Of course, you're not 3D printing the ESP32-CAM, and you'll need that too. To be precise, the things you might need are:

1. A 3D printer and filament
2. ESP32-CAM module including OV2640 camera module; the design assumes you are using the AI Thinker version or any of the compatibles available with various branding
3. A mechanism for programming the ESP32-CAM, which usually means a computer with the Arduino environment and a serial to USB converter such as is often included as a USB interface boardlet with a socket for the ESP32-CAM boardlet; this USB programming interface is not needed once the ESP32-CAM has been programmed
4. A 5V power supply that can steadliy deliver up to 500mA; this can either be a USB power source and cable or a 9V (preferably rechargeable) battery with either a 7805 voltage regulator (discouraged due to wasted energy and heating) or a 5V buck converter -- the one I used is this Teyleten with this 9V battery clip
5. A way to make the electrical connections; wire wrap and/or soldering can work well
6. Optionally, an 8x8mm NIR-blocking filter; without this, your KISS Viewer will be a full-spectrum camera that does not deliver accurate colors for normal shooting
7. Some glue and/or tape
8. A device you can use to control the KISS Viewer camera via 2.4GHz 802.11 WiFi accessed via a web browser; note that, like most IoT devices, the ESP32-CAM does not support 5GHz 802.11, but KISS Viewer acts as a soft access point making its own network (it does not need internet access)

The parts and materials that go into building each KISS Viewer should cost less than $30, although you might have trouble getting some parts in unit quantity.

Obviously, there's a lot to 3D print in this design. The STL models are freely available from KISS Viewer at Printables.Com and the plan is to keep that as the single primary source for the latest 3D models if any changes are made. Perhaps surprisingly, there is literally not a single mechanical part you can't print on a typical consumer FDM. The basic stand is too large for some printers, but a two-piece version is also posted. Even the screws are printable, and screws for adjusting tilt are reinforced for strength using printable inserts.

The assembled KISS Viewer would fit in a cylinder 260mm tall with a diameter of 144mm -- which is fairly large for a 3D-printed object. All parts are designed to be printable without supports using a typical FDM printer with a 0.4 mm nozzle. Each part is in a file named with the prefix "viewer_". Although most parts should be strong enough using default print settings, parts 3 (or 11 and 12), 6, 7, 8, and 9 are potentially prone to breaking at layer interfaces. Printing those parts with thicker walls or stronger infill wouldn't hurt, and enabling infill combination in your slicer can significantly help avoid cracking at layer boundaries while also reducing print time.

To most closely match the look of a Tower Optical Viewer, I recommend printing parts 1, 2, 6, a second 6, and 7 using Silk Metallic Silver PLA. Parts 3, 4, and 5 should all be the same material, with good choices including Black PLA, Dark Green PLA, and Silk Metallic Silver PLA. Parts 11 and 12 are essentially an alternative to part 3 that has been broken into two pieces that screw together for those with printers that can't handle anything over 120mm tall. Part 6a and a second part 6a basically are rectangular cores to go inside the part 6 prints and can be printed in any material. Because these cores are printed in a different orientation, inserting (and gluing) them into the Part 6 pieces greatly increases the strength of those parts, which is important because they provide the clamping force to keep a mounted lens from drooping. Part 8 is the locking pin to hold an E/FE-mount flange in place, and it can also be printed of any material. It is screwed partially into the inside of the camera's E/FE-mount and tightened using a screwdriver to lock a lens in place after the lens has been mounted. Part 9 is the mount for the ESP32-CAM boardlet, and it can also be printed using any material. Finally, part 10 is an optional holder for an 8x8mm NIR blocking filter. Once the native lens has been removed from the OV2640 that came with the ESP32-CAM, it also no longer has an NIR (near infrared) blocking filter. Thus, if no NIR blocking filter is added, KISS Viewer is full-spectrum sensitive. Full spectrum sensitivity means that NIR scene content down to around 1050nm is recorded and visible light colors will be altered by this NIR light.

Note that you can get an even shinier chrome look by painting printed parts with silver paint rather than using Silk Metallic Silver PLA. However, you need to be careful not to have the paint interfere with part functionality -- which would most likely happen for the E/FE flange surface and screw threads. You can also use flat black paint to minimize reflections and seal light leaks within the body (parts 1 and 2), but in practice this does not seem to be an issue.

Before assembling anything, perhaps while the parts are printing, I recommend programming your AI Thinker ESP32-CAM boardlet using the ESP32 Arduino environment. You will need not only the ESP32-CAM, but also a USB serial converter for programming it. The programming process, and much more about using the ESP32-CAM, is detailed by a Random Nerd Tutorial. In fact, the code used in the tutorial demonstration is almost exactly what you want to program the part with for the KISS Viewer, and you could use it rather than my version. My code is mostly a set of minor edits applied to the CameraWebServer demo code that comes with the ESP32-CAM Arduino environment. There are two catches:

1. The OV2640 camera module always contains the same sensor, but it isn't always in the same orientation relative to the cable that connects it to the ESP32-CAM board. The 1600x1200 pixel sensor is typically set such that the 1600 dimension in is the direction of the white text printed on the cable, which might be portrait or landscape orientation when mounted in KISS Viewer depending on the particular OV2640 you get. Most sellers are not consistent about which you get, although the portrait version seems most common. Unfortunately, the OV2640 controller doesn't know how to rotate the image 90 degrees, which is what you'd need for the portrait version to produce an upright live view. My code uses JavaScript in the HTML interface to add a button for toggling 90-degree image rotation of the live view.
2. The 2.4GHz 802.11 interface in the ESP32-CAM must be configured at compile time to connect to a specific network using the sample code, so it would not work without that 2.4GHz network. Many home networks no longer provide a 2.4GHz option and, even if yours does, you would only be able to use KISS Viewer on the 2.4GHz network you compiled it for. Thus, my code has the (default) option of KISS Viewer establishing its own 2.4GHz 802.11 network that you can connect to with your computer or smartphone.

I strongly recommend programming the part and testing it using the native lens before assembling KISS Viewer. To make it more obvious whether you are running the original demo code or my version, the HTML interface produced by my version of the code identifies the device as KISS Viewer, and all the controls have blue colors from the official University of Kentucky color scheme rather than the red shades of the demo code.

At this writing, the current version of my code is kissviewer260909, available as https://aggregate.org/DIT/KISS/kissviewer260909.tgz or https://aggregate.org/DIT/KISS/kissviewer260909.zip. The latest version should always be linked from https://aggregate.org/DIT/KISS/. Details about how to use it are in the Software User Guide below. The software interface is not affected by the choice of using the ESP32-CAM with the native lens vs. using it in the fully assembled KISS Viewer with an adapted lens.

Using KISS Viewer is straightforward, but the HTML page interface provides a surprisingly wide array of camera controls for the OV2640. Once you have powered-up KISS Viewer, connect your computer or smartphone to its 2.4GHz 802.11 wireless Ethernet network, which by default is named KISSViewer with the password kisskiss. Be warned that if you try to set the password to something fewer than 8 characters long your request may be ignored and the network may be named something starting with ESP no matter what the source code requests it be named. Once connected, set your WWW browser to access the URL "http://192.168.4.1". That should bring up the KISS Viewer control page shown above.

Initially, the page will not have an image displayed; that's enabled by one of the buttons near the bottom of that scary-long menu. You can find more about these options in various places on the WWW, but here we will briefly cover the most significant:

1. XCLK MHz: This clock essentially scales the speed of the camera processing. The default setting is 20, but dropping to lower numbers also slows sensor scan rates and thus can enable shooting in lower light with less noise. The camera is also less likely to suffer glitches at lower settings.
2. Resolution: The OV2640 is a 1600x1200 pixel sensor, but can downscale images to smaller sizes to reduce the JPEG file size, thus enabling higher framerates for live view. 640x480 is a good compromise to speed composition and focus during live view, but 1600x1200 isn't that slow, typically delivering several frames per second.
3. Quality: Lower numbers here mean higher quality. JPEG DCT block artifacts become quite visible at higher numbers; I recommend staying close to 4.
4. Brightness, Contrast, and Saturation: These adjust what you'd expect, but are implemented purely in processing the JPEG -- they don't alter how the sensor captures the image and thus are not as useful as you might have hoped.
5. Special Effect: The sensor uses an RGB Bayer filter for color capture, and the "No Effect" setting delivers reasonable color images. The only other effect I find useful is "Grayscale", which produces good quality monochrome images with correspondingly smaller file sizes.
6. AWB, AWB Gain, and WB Mode: These settings alter white balance in the JPEG. Leaving them set as on, on, and "Auto" is usually what you want.
7. AEC SENSOR: This is basically your shutter speed control, implemented by dynamically adjusting electronic rolling shutter scan rate. In on, it is automatically adjusted. If off, a manual exposure slider appears that allows you to set scan speed to have from 0 to 1200 units of delay, so higher numbers scan slower, letting the sensor see more photons.
8. AEC DSP: This attempts to tweak exposure to correct for complex scene content, but often is overly aggressive. Consider turning it off.
9. AE Level: This is basically a brightness control that is applied as an offset to the sensor integration time. In other words, it is your exposure compensation control.
10. AGC and Gain Ceiling: This controls the analog gain applied while digitizing pixel values. AGC automatically adjusts this within the allowed range is on, but you get full manual control with it off. Boosting gain dramatically increases sensor noise, and sensor noise gets ugly fast. In low light, you are better off reducing XCLK MHZ and increasing delay for the rolling shutter.
11. BPC and WPC: These respectively apply corrections to the black point and white point, which typically improves JPEG quality (however slightly).
12. Raw GMA: Although the OV2640 can capture raw 10-bit data, there is a problem with DMA of the raw data to ESP32 memory. This option allows JPEGs to be created with a decent approximation to linear gamma, thus providing better dynamic range and a reasonable approximation to "raw" pixel data.
13. Lens Correction: This basically corrects for corner shading, which is largely about marginal rays not being fully detected, and is thus less lens-dependent than you might think. However, this vignetting correction is not as effective as one might hope because boosting brightness quickly hits dynamic range limitations. I generally leave it off when using Raw GMA.
14. H-Mirror and V-Flip: These do precisely what they say, but note that Horizontal and Vertical are relative to the sensor, which is often mounted 90-degrees turned.
15. DCW (Downsize): This enables scaling using DSP resampling to the requested resolution, whereas turned off uses only resolutions that the hardware directly supports. I generally leave this off.
16. Color Bar: Ignores sensor data and renders a test color bar image.
17. LED Intensity: Keep this off! This controls a bright white LED that is on the boardlet and hence behind the E/FE mounted lens on KISS Viewer. I suppose that it could be used for controlled fogging...
18. Toggle Rotate: This is not a standard control for the OV2640, but a simple mechanism for rotating images in the display so that they can match the sensor orientation in KISS Viewer. Note that this option only rotates the display of the image, not the image data.
19. Get Still: Capture and display a fresh still image.
20. Start Stream: Begin capture and display of a stream of JPEG images. Logically, this is requesting motion-JPEG video capture, but the frames are treated as individual JPEG captures. The repetitive nature of this capture mode can cause electrical interference patterns that show in images as structured noise, often lines in the 1600-pixel dimension. This is best treated as a live view mode for composition and focus rather than for capturing best-quality images.
21. Advanced Settings: Don't touch these unless you know what you're doing. However, the OV2640 does have support for things like ROI (region of interest) sampling if you need fancier control.
22. Save x: Two buttons with these labels will appear to the right of any displayed image. Clicking the Save button will save the current JPEG image.

Of course, there is no electrical coupling to the E/FE mount or any lens attached. Thus, focus and aperture control are entirely manual. There also is no mechanism for including useful EXIF data in an exposure. In fact, the ESp32-CAM does not have a clock that runs while power is off, so even timestamps are not feasible. On the other hand, saving an image on your computer or smartphone will generally tag the file with a timestamp.

The photos of plants included here were shot using a smartphone to control KISS Viewer with a Mamiya/Sekor 55mm f/1.8 lens mounted via a M42-E/FE adapter that happens to be my 3D-printed design. The particular ESP32-CAM I used has its OV2640 in portrait orientation, so the images had to be rotated 90 degrees to be upright, but no other processing was needed.

Now that you've printed everything and gotten the software ready, it's time to assemble everything. None of the 3D-printed parts should require significant post-processing, and I refer to them here by the STL file part numbers, which are also shown in the figure in the Print the Parts section above. Assembly isn't difficult, but there are quite a few steps:

1. If you printed part 11 and 12 instead of part 3, you can screw (and optionally glue) those parts together to create what is effectively your part 3.
2. Part 4 should be glued into the indentations in part 3 and given time for the glue to set. Alternatively, the parts can be welded together using a soldering iron. Note that the part 4 ring has a large enough internal diameter to easily pass over the top of part 3.
3. Glue part 5 into the indentations in part 4 and let the glue set. Alternatively, the parts can be welded with a soldering iron. Note that the part 5 ring has a large enough internal diameter to easily pass over the top of part 3.
4. Both pairs of parts 6 and 6a need to have the rectangular 6a parts glued into the slot in part 6 as a stiffener. The better the glue bond, the stronger these parts will be; I used cyanoacrylate glue.
5. Mount the ESP32-CAM boardlet on part 9. Part 9 is essentially a circuit board without traces, and the ESP32-CAM boardlet should be mounted into it such that the wings of part 9 line up with where the OV2640 imager is and the boardlet is pushed in so that the pins protrude as much as possible from the indented side of part 9. In other words, the ESP32-CAM board goes on the side that is the bottom of part 9 in the print orientation. The ESP32-CAM boardlet can be tacked in place using a few spots of hot glue, but try to avoid encasing any active components in hot glue so that they can stay cool more easily while operating.
6. The ESP32-CAM's OV2640 native lens is screw-mounted with a tiny thread, but to keep the focus fixed, it is generally tacked in place with Loctite or a similar glue. Take the OV2640 module as a separate part, not connected to the ESP32, and hold the square base of the chip module with one pair of pliers while using a second pair to gently loosen the native lens by turning it counterclockwise until it is free to remove. KISS Viewer does not use that lens.
7. Lock the OV2640 cable into the ESP32-CAM boardlet's connector. Some OV2640 modules come with self-stick backing; if yours did, peel off the backing and press it to the flat metal of the TF card slot casing. If yours isn't self-stick, use a dot of glue to hold the OV2640 in place. Don't use hot melt glue because the camera gets warm enough for that to distort and leave the camera module flapping around. The raw sensor of the OV2640 module is exposed throughout this, and the pixels are tiny compared to dust spots, so be careful not to contaminate the sensor while handling it.
8. Optionally, mount the 8x8mm NIR blocking filter to give the camera accurate visible-light color rendering. Use tweezers to place the 8x8mm filter into part 10, then place that over the OV2640 module. Use heat-resistant glue to lock part 10 and the NIR filter in place against the TF card holder. With the NIR filter in place, the OV2640 sensor is somewhat protected from dust, and dust landing on the NIR filter is far enough in front of the sensor that the shadow it casts typically isn't problematic until lens apertures around f/11 or higher.
9. Mount part 2 within the fork of part 3 using the 6+6a screws. Don't overtighten -- we know you are stronger than the 3D-printed screws. ;-)
10. It is now time to solder the power connections to the ESP32-CAM. I'm a big fan of using a wire-wrap tool to connect to the pins, then soldering. If you don't have a wire-wrap tool, for two pins it isn't hard to manually wrap a wire around each pin using tweezers. Viewing the ESP32-CAM from the back, the top pin on the left side should be connected to 5V and the pin just under it to Ground. No other connections are needed for operation, although USB serial access and programming the ESP32-CAM require additional connections, respectively, on two or four pins. The 5V power can come either from a USB cable snaked up through the stand and base of part 2 (before soldering to the boardlet!) or from a standard 9V battery regulated to 5V with the battery resting on the shelf inside part 2. I originally used ye olde 7805 regulator from a rail of them I had lying around, but it gets unpleasantly warm dropping 9V to 5V. There are now many buck converter boardlets that are much more efficient (e.g., 96% vs. 56% for a 7805); just make sure the one you pick can handle a steady draw of at least 500mA. The one I used is this Teyleten, which costs less than $1 each, does not require adjustment to output precisely 5V, and is rated to supply 2A without problematic heat dissipation. Whichever regulator you are using can be glued down over the cable hole at the bottom of part 2.
11. Mount an E/FE lens on the unit. You can use a screwdriver to adjust the E/FE lock screw to keep the mounted lens from rotating.
12. Slide part 9 into the slots on part 2, power it on, connect your web browser, and turn on live video view. The positioning of part 9 is supercritical in establishing the focal plane of the camera. Aim the camera at something distant (looking through the viewer holes makes aiming easy) with the lens aperture wide open and focus set to slightly closer than infinity. This will allow focus slightly beyond infinity with the lens used for adjustment, but that might be necessary to ensure infinity focus for adapters or lenses that are slightly miscalibrated or for lenses that change infinity focus depending on ambient temperature. The appropriate distance should have the ends of the rails of part 9 within a few mm of where the slots end and part 1 will be mounted. While watching the live view, move part 9 along the slots. You want the entire image to be sharp. Minor tilts will, through the Scheimpflug principle, result in tilting the plane of focus more than you'd expect. Although you could use this tilt ability to your advantage under specific circumstances, you don't want the focal plane tilted for normal use. Once you have part 9 well aligned, I recommend locking it in place with a little hot glue in the slots.
13. The final step of assembly is mounting the viewer-side cover, part 1, on part 2. The cover is deliberately held by a single screw, part 7, so that it can easily swing out of the way to access the inside of part 2. Such access is necessary to change the 9V battery, unlock the E/FE lens mount, or to re-adjust the focal plane. Part 7 is a little awkward to screw in because it is designed to look like the focus adjustment on a Tower Optical Viewer, but take your time and don't overtighten it. Also avoid pulling against it when you swing part 1, because that leverage can break the thread off. The KISS Viewer is actually fully operational without part 1 mounted, but part 1 does serve as a light shield and 9V battery slot stop.

Now that you've built a KISS Viewer, you need a lens for it. A manual lens, because KISS Viewer doesn't have any electrical connection in its E/FE lens mount. The lens also doesn't need to be E/FE mount, but merely adaptable to it -- and "dumb" 3D-printable adapters like my Mamiya Sekor-compatible M42 Lens To Sony E/FE Body Adapter are viable options.

The Tower Optical Viewer specifications say it gives 10X optical magnification with a field of view of 318 feet at 1,000 yards, which is a roughly 6-degree view angle. A "normal" lens giving a 1X magnified view on a full-frame camera would have a focal length approximately equal to the diagonal of the image produced, which is sqrt(36^2+24^2), or roughly 43mm. 10X times 43mm would be 430mm as the ideal full-frame focal length to match the Tower Optical view. Given that our OV2640 has a crop factor of about 9.7X relative to full frame, the matching focal length would be 430mm/9.7, or roughly 45mm. For technical reasons, most lenses sold as normals for full-frame cameras are a bit longer, between 50mm and 58mm, but that's a pretty good approximation to the same view. Thus, I'd suggest starting with an old manual "fast fifty" lens -- like the 55mm f/1.8 Mamiya/Sekor in the photo above.

Although I tested KISS Viewer with lenses from 24mm to 300mm, long focal lengths are insanely difficult to aim because of that 9.7X crop factor: a 300mm lens behaves like a 2910mm lens! Very short focal lengths work, but a conventional camera will do better at delivering wide view angles. I think lenses in the range from about 35mm to 135mm make the most sense for KISS Viewer.

You're probably wondering about the image quality, and you should. Most lenses would not crisply resolve pixel-level detail for a full-frame sensor with 2.4um pixels (which would be a 150MP sensor), but our OV2640's 2.4µm pixels are just sampling the central "sweet spot" of the image, and that's often fairly sharp. Of course, diffraction effects will quickly degrade image quality at higher f/numbers. Fraunhofer diffraction for 530nm green light is already making a spot size greater than 2.4µm at f/2.0, but if you were happy with the level of diffraction of your lens on a 24MP full-frame camera at f/14, up to around f/5.6 should be OK with the OV2640 -- this system will be about two and a half stops more sensitive to diffraction.

Happily, old manual lenses in the 35mm-135mm range are often both inexpensive and have low f/numbers. "Fast fifty" lenses are usually f/2 or brighter. However, there are also plenty of new manual lenses with the right properties, such as the PerGear 35mm f/1.4. Keep in mind that even lenses designed for APS-C or MFT sensors are fine for the tiny OV2640 sensor. Many C-mount lenses are also fine, but be aware that newer C-mount lenses are often designed for sensors with very low pixel counts, and they might not be appropriate for KISS Viewer.

When you mount your lens on KISS Viewer, it mounts very much like it would on any Sony E/FE mount body. The biggest difference is that KISS Viewer doesn't have a lens release button: instead, you lock the lens in place by using a screwdriver to turn it to extend the E/FE lock pin from inside the unit. A lens cannot be removed from KISS Viewer while the pin is extended.

There is really just one trick to shooting with KISS Viewer: hands off! Basically, you set the unit on a solid surface, or mount it on a tripod via the 1/4-20 threads on the bottom of the unit, aim it, focus, and don't touch it. At the extreme effective focal lengths KISS Viewer provides, even the slightest vibration will result in wild motion that is distorted by the relatively slow electronic rolling shutter.

Powering KISS Viewer via a USB cable is definitely the best method if you don't intend to move the camera around much. For example, if you always have it pointed out a window at a bird feeder. For carrying it around, I prefer to use the 9V battery-powered version, so there's no USB cord and external power supply. Here's the process:

1. Put the battery in the unit, which will turn on the system and establish the KISSViewer network
2. Connect your smartphone or laptop to that network (using the default password kisskiss), start a web browser with the address http://192.168.4.1, and select Start Stream
3. Place the KISS Viewer on a stable surface or tripod
4. Loosen the tilt screws, sight through the viewing holes to find your target, and tighten the tilt screws enough to hold (do not overtighten)
5. Looking at the live view in your browser, very gently make small adjustments to the aim and focus of your lens; this will be an iterative process, letting the image settle after each adjustment
6. Now adjust the other settings via the browser
7. Stop Stream and Get Still
8. The Save button can be used to save the displayed image into a file, however, it might only save at the displayed resolution rather than the capture resolution; on my smartphone, I can save at full capture resolution by holding my finger on the displayed image to pop-up a file save dialog
9. When you are done repeating any of steps 3-8 as many times as desired, simply remove the 9V battery

This process works not only for viewing distant objects, but for shooting macro images from remarkably far away. The 9.7X crop basically means an ordinary lens that can capture full frame at 0.4X life size behaves like a 3.88X super macro while at the same subject distance!

It is worth noting that the ESP32-CAM steady-state power consumption is around 180mA @ 5V, occasionally spiking to over 300mA while capturing images. 9V battery capacity varies widely, but even the wimpiest should give over an hour of runtime through a good 5V buck converter. The catch is that all the power in comes out as heat. You might have noticed that the mount for the ESP32-CAM boardlet leaves as much airflow as possible around the actual ESP32 processor chip, but the OV2640 camera itself draws between 30-50mA @ 2.8V as the AI Thinker boardlet controls it. In other words, continuously running the camera can get it hot too. The metal plate for the TF card slot acts as a bit of a heat sink, but the camera can still glitch due to heat buildup over a longer runtime. If you need longer runtime, consider mounting the OV2640 on an actual heat sink and then bonding that to the TF card slot housing.

Of course, you can postprocess the captured JPEG images any way you want... but I'm a computational photography researcher, so of course I wrote custom software tuned for postprocessing of KISS Viewer OV2640 captures. That software is called postkiss and I am making the C++ source code freely available under CC BY 4.0. Be warned that this software is "research grade" -- i.e., it works well enough to validate the concepts, but is by no means a carefully debugged, polished, or well-maintained production code. You can get the latest version of postkiss source code at https://aggregate.org/DIT/KISS/#postkiss.

Before describing the postkiss image postprocessing software, here are a few disclaimers. Postkiss is quite sophisticated, which makes it shockingly slow: it can take up to a minute to process each image. Still, no matter how exotic the postprocessing, the image quality that can be obtained while being faithful to a scene captured with an OV2640 is not very impressive. This software is also very far from a polished product; it's a somewhat messy research prototype based on an earlier research prototype called postkamf, which I created to maximize image quality of captures from either version of the KAMF modified kid's cameras that use 640x480 pixel sensors.

Here are a few simple postkiss command lines and what they do. In each case, the input images are expected to be in the usual unturned 1600x1200 orientation, and that's also how the output is generated. The output file is a 16BPP PNG named postkiss.png by default, which you can turn and process further with any image editor. The PNG output file tends to look darker than the original images due to gamma linearization for processing, but this is easily adjusted in your favorite image editor; the generated PNG is conceptually more like a raw image than a JPEG. Also, because we know the sensor is actually 1600x1200, postkiss internally scales all images to that size before operating on them.

./postkiss capture.jpg

Compute a statistical pixel value error model for the image capture.jpg and apply noise reduction using it; this is essentially a version of the kremy (KentuckY Raw Error Modeler) algorithm described in my Electronic Imaging 2022 paper, An improved raw image enhancement algorithm using a statistical model for pixel value error.

./postkiss -w white.jpg capture.jpg

Same as above, but first correct the image vignetting and color casts using the reference white image white.jpg, which should have been captured with similar camera settings of a featureless white surface, such as a blank white wall out of focus.

./postkiss -w white.jpg capture0.jpg capture1.jpg ...

Same as above, but also apply subpixel alignment to capture0.jpg using the set of images to create a default 2X (linear dimensions; 4X total pixel count) superresolution image. The captures are assumed to be taken with very little movement between shots; the processing was created for superresolution merging of pixel-shift image sequences, using the parsek (Probabilistic Alignment Raw Stitcher Experiment from Kentucky) algorithm as described in my Electronic Imaging 2024 paper, Leveraging Pixel Value Certainty in Pixel-Shift and Other Multi-Shot Super-Resolution Processing. The extreme effective focal lengths for KISS Viewer magnify tiny vibrations so that a sequence of shots typically has roughly the same magnitude of misalignments found in pixel-shift sequences.

The photos here include both and reference white image and examples of the last two sample postkiss command line uses.