Enable Raspberry Pi Camera Module 3 Wide after Arducam 64mp

My development pi has had an Arducam 64mp camera connected for my camera software development. I liked the quality of the camera but have at various times been frustrated with the software requirements to use the camera. It’s required both a custom kernel driver and a custom fork of the libcamera software packages. That’s meant that to use the 64mp camera I needed to reinstall the arducam suite after nearly every apt upgrade cycle, and definitely ones where the system kernel got updated.

I spent several days trying to get the remnants of the arducam64mp removed from my development system. I’d even built a fresh sd card image of Raspian Bullseye to make sure that the hardware was all connected and working properly.

In the end the fix was rather simple, if obscure.

First, remove or comment out the dtoverlay line from the /boot/config.txt file and make sure camera auto detect is enabled.

# dtoverlay=arducam-64mp
camera_auto_detect=1

Then run apt install with the –reinstall option for the libcamera packages and the raspberry kernel package.

sudo apt install --reinstall -y libcamera-apps libcamera-dev libcamera0 raspberrypi-kernel
sudo systemctl reboot

Then reboot. That should be then allow you to run libcamera-hello and verify that the new camera is working.

I’d found a reference How To Enable RP Cam V2 After Arducam 64MP that didn’t seem to work for getting the V3 wide camera working, perhaps because the focus hardware in the V3 camera made the 64mp think it was active.

I asked the question of how to remove the drivers on the Arducam Forum and then answered my own question.

On to playing with my new Camera Module 3! (I bought the Arducam cases from Amazon because I really liked the fit. The new wide camera protrudes from the front with enough clearance for the focus to function.)

Horizontally flipped image of Shilshole Bay Marina

I got an email this week from the Port of Seattle Shilshole Bay Marina that concluded with an image that is reversed. At first glance it looks like it was taken from the south looking north with Puget Sound to the left. Then I realized nothing was in the right place. This image is looking south with Puget Sound (west) on the left.

In photography with slides this could be a simple mistake but in modern digital photography this requires effort to flip the image. I wonder if this was intentional to see who would comment about it, or a sign of much worse things.

Arducam Red Tint Issue on Raspberry Pi

no tuning file

After writing up my issue yesterday I posted the question on the amazon product details. I received an answer with a link to this page overnight. It references a page with several custom tuning files for their lenses. There did not seem to be a tuning file that matched the 175° FOV lens on the package I got, but there was both a 160° and a 200° version. I downloaded both files and ran a test capture with each. On initial viewing, either will work for my solution. I need to focus the lens to see if there are any noticeable differences.

–tuning-file imx219_160.json

–tuning-file imx219_200.json

The commands I used to download and test the tuning files are

wget https://www.arducam.com/wp-content/uploads/2022/05/imx219_160.json
wget https://www.arducam.com/wp-content/uploads/2022/05/imx219_200.json
libcamera-still -v 2 --nopreview --hflip --vflip --thumb none --tuning-file imx219_160.json --output `hostname`-160.jpg
libcamera-still -v 2 --nopreview --hflip --vflip --thumb none --tuning-file imx219_200.json --output `hostname`-200.jpg

I got a message about the tuning file being an older version, with pointers on how to convert it to the updated version.

WARN RPiController controller.cpp:43 This format of the tuning file will be deprecated soon! Please use the convert_tuning.py utility to update to version 2.0.

I still need to decide how I want to handle this in my automated photo processing, but having the information is hugely useful.

Links in one place:

• Arducam 8MP IMX219 175° Raspberry Pi Camera Module https://www.amazon.com/gp/product/B09VSVB4DT/
• Lens Shading Calibration https://www.arducam.com/docs/cameras-for-raspberry-pi/native-raspberry-pi-cameras/lens-shading-calibration-2/
• Lens Shading JSON File https://www.arducam.com/lens-shading-json-file/

GoPro Flat Mount

I’ve had GoPro mounts fixed to either side of the boom of the sail boat I race on for several years. I primarily use the one on the starboard side, producing videos of races like the one below.

Last week the camera got caught in the reefing line as we raised the main sail, pulling the sticky mount completely off the boom. From past experience dropping the Gopro on the boat, I use a safety cord tied to the camera, so did not lose the camera.

This week I visited the boat the day before our race and installed a new mount on the boom. I also made sure that the reefing lines were resting on the port side of the boom so the camera wouldn’t be caught during the raise.

Soon after we had raised the main and taken a couple of tacks, the camera had shaken itself off the boom. The sticky pad didn’t stay stuck to the boom.

After I got home, I peeled the remainder of the sticky pad from the old mount with a lot of effort. I was able to peel the sticky pad from the new mount easily and in one piece.

The old mount is top right, the new mount is bottom left. An unused mount from my GoPro box is bottom right.

At one time I purchased a bunch of GoPro mounts in a kit from Amazon. The kit had a chest strap that was significantly cheaper than the original GoPro branded one. It was worth the price for me. I noticed that if I kept the new items in a Ziploc bag, the plastic had a distinct smell, while the original GoPro plastic did not. Knowing what I do about plastics, I didn’t want to trust my GoPro to the cheap plastic, unfortunately after having things sit around for a couple seasons I forgot that.

I believe the mount with the voids under the groove edges are from the inexpensive package. Along with questionable plastic, I believe it also used a less sticky adhesive pad.

I’ll try replacing the mount with the remaining original this coming week and hopefully be able to record another race

Windows File Recovery from Microsoft

Last week Microsoft released a new command line tool in the Microsoft Store. It requires running Windows Version 2004.

Last year when I was importing pictures from a camera memory card, the import program crashed. It only managed to import a few of the pictures, but it deleted all of the pictures from the memory card.

Because of my long history understanding how file systems work, I knew that the pictures were likely still on the card, just not in the directory system I couldn’t find a tool at the time to recover the files. I’d put a label on the card and set it aside. As soon as I heard about this program I installed it and tried it out on the memory card.

The funny thing is that it recovered several thousand images, going back several years. I ran it in signature mode, looking for jpeg files. In doing that, It’s just looking at all the data blocks on the drive, looking for jpeg files.

This time I used Adobe Lightroom CC to import the images and group them by the embedded EXIF data. Looking at the details, the photos that got deleted by mistake were likely from 10/28/2018. All of the photos attributed to 06/29/2020 are missing exifdata, and are just recorded as the date they were recovered.

This is a good reminder that you probably don’t want to throw away old digital media, even when you think you’ve gotten rid of all incriminating data.

https://storebadge.azureedge.net/src/badge-1.8.4.js mspb(‘9n26s50ln705’, function(badge) { document.getElementById(‘mspb-yfhgln7xadp6’).innerHTML = badge; });

Raspberry PiZeroW Camera Module

When you’ve gotten used to Amazon Prime and free shipping, purchasing inexpensive items from other online retailers where the shipping doubles the cost of the item makes it harder to impulse buy items. An item for $5 that costs $7 in shipping often doesn’t get bought. Even a pair of items that cost $16 together that then cost $7 in shipping cause me to delay the purchase.

Because I was purchasing a Raspberry Pi 4 and Raspberry Pi USB-C Power Supply from Sparkfun, I decided to throw in another Pi ZeroW and case for another $16. I then added the Raspberry Pi Camera module because the case has an optional cover enclosing the camera and I wanted to see how it all worked together. I only wish I’d realized that there was a Noir version, because I’ve always wanted to play with infrared photography.

Having recently streamlined the installation of a Pi Zero, I installed the camera and Pi ZeroW in the case, put the configured micro sd card in place, plugged it into my HDMI monitor just to watch it boot and applied power. I never saw anything on the monitor. The Pi ZeroW only has a single LED, which is generally on, but blinks for micro sd activity. Because I’d closed the case, the LED wasn’t visible, and with no monitor activity I was wondering if I’d gotten a bad board.

I opened the case and powered it on again, this time I knew I was seeing LED activity. I did a quick search of my network for new devices and found the new board was responding on ssh and appeared to be working correctly other than no HDMI output.  I was even able to take a snapshot with the camera using the command:

raspistill -o image.jpg

I decided to test booting the device without the camera installed. That worked fine, and I had HDMI output during the boot process. Now I started to wonder if perhaps the power supply I was using didn’t provide enough power. Perhaps the camera and the HDMI device were mutually exclusive in the amount of power required

A lot of searching on the web resulted in nothing about the power required for the camera affecting the HDMI output. I found that I might be able to reduce the power requirements by 25mA by turning off the HDMI, but that the Pi ZeroW was already the lowest power draw available. https://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-pi-zero-conserve-energy

I found the tvservice command and the -s option with the camera installed was resulting in a different result from without the camera installed.

pi@WimPiZeroCamera:~ $ sudo /usr/bin/tvservice -s
state 0x40000 [NTSC 4:3], 720x480 @ 60.00Hz, interlaced
pi@WimPiZeroW:~ $ sudo /usr/bin/tvservice -s
state 0xa [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressive

At least recognizing that difference was progress. For some reason under Raspian Buster the camera module is causing the HDMI output to be different. I found options in https://www.raspberrypi.org/documentation/configuration/config-txt/video.md that allow me to force the HDMI output to what I want. I changed /boot/config.txt with the following and now I’ve got both camera and video working properly.

# uncomment to force a specific HDMI mode (this will force [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressive)
hdmi_group=1
hdmi_mode=16

I hope that this helps someone else having problems with both camera and hdmi video output. I don’t know if this was specific to Buster since I never tried it under Jessie or Stretch.

FFMPEG and h.265

I’ve noticed that YouTube transcodes my videos after I upload them and wanted to know more. It turns out that they are internally using a form of h.265 video encoding, which reduces the data size significantly without reducing perceived quality over h.264 video compression.

I decided to run some tests using my GoPro time lapse program to see how much compression I’d get versus how much extra time for encoding.

First I had to read up on the settings for using h.265 in FFmpeg. According to https://trac.ffmpeg.org/wiki/Encode/H.265, If I add -c:v libx265 into my existing FFmpeg command line without changing anything, I’ll get an h.265 output with the defaults of -crf 23 and -preset medium.

The -preset value effects how much work is done in the compression, but shouldn’t affect the perceived quality. It will effect both time to create and output file size.

The -crf value effects the perceived quality. I’ve been using the defaults in my previous h.264 mp4 files, which should be approximately -crf 23 and supposedly -crf 28 in h.265 is equivalent to the lower h.264 value. A -crf 0 would be a completely lossless conversion. For my tests, I left crf at the default 23.

I ran all of these tests on a set of 7,129 photos I’d captured while sailboat racing on March 24th using my GoPro Hero 3+ Black. Each input image was 4000×3000 and I’m creating an output video with resolution 3840×2160 by cropping it at 3/4 of the height and scaling to fit.

The original h.264 conversion took 28:36 minutes to create and was 1,162,079,866 bytes long.

Here’s a trimmed down and sorted file listing. The first column is the time it took to create, second is filesize, and third is filename.

28:36 1,162,079,866 20180324-2160p30-cropped-h264.mp4
30:25 1,006,292,960 20180324-veryfast-2160p30-cropped-h265-crf20.mp4
21:35   328,700,100 20180324-ultrafast-2160p30-cropped-crf28.mp4
21:59   339,438,778 20180324-superfast-2160p30-cropped-crf28.mp4
25:12   350,085,434 20180324-veryfast-2160p30-cropped-crf28.mp4
25:17   349,720,030 20180324-faster-2160p30-cropped-crf28.mp4
27:24   348,582,310 20180324-fast-2160p30-cropped-crf28.mp4
52:07   365,050,252 20180324-medium-2160p30-cropped-crf28.mp4

I created a single test at -crf 20 because I was interested in seeing a higher quality video and how different it would be in size. It took slightly longer than the original h.264 compression and had a slight improvement in size.

Two things became obvious to me from this test. More time spent in compression doesn’t always mean better compression. For my application, running preset medium actually hurts the performance, both in file size and time taken.

I ran all of these tests only a single time on my desktop computer with an Intel(R) Core(TM) i7-4771 CPU @ 3.50GHz, 3501 Mhz, 4 Core(s), 8 Logical Processor(s) running the latest version of Windows Version 10.0.16299 Build 16299. I was running FFmpeg version N-88668-g723b6baaf8 from https://ffmpeg.zeranoe.com/builds/. The variations in time could be related to background tasks running on the machine, and I should have run a more comprehensive battery of tests, averaging time and with more accurate timekeeping.

Public Art in Ballard

Last fall there was some art in the Ballard park that I found interesting. I mainly found it interesting because at first I didn’t notice it was art at all, just thought it was some safety signs.  Each reflective metal sign was affixed to a light post in the park, with a zip tied laminated paper description below. They were not all together.

Lily Pond

Lily Pond, Washington Park, Chicago, Ill., U. S. A.

This is the last of the stereograph pictures I had to scan, and the only one in color. It’s interesting how only the green color remains.

I don’t know if a color photography system was originally used and the colors other than green have faded, or if the color was added later. I suspect the former.

Spanish Torpedo

Spanish Torpedo Taken from Harbor of Santiago.

In modern warfare explosives are coming more and more into use. Streets and thoroughfares as well as rivers, straights and harbors over which it is thought the enemy may pass, are mined with deadly explosives sufficiently powerful to wreck the mightiest battleship or overwhelm a large land force. Torpedoes are usually made in forms similar to a cigar, so that they may be projected under water, the sharp end going forward. As is well known, they can be arranged to explode by contact, a time fuse, or an electric wire. The sample death dealing instrument shown in this view provided with contact arms which, when struck, thrust a spike into the interior as shown, causing explosion by percussion. Doubtless it was some such contrivance as one of those described above, which, on Feb. 15th, 1898, tore into shred and sent to the bottom of Havana Harbor, our proud battleship “Maine,” together with nearly her entire crew.