Raspberry Pi Kernel 6 and Arducam

I updated the software on my development machine this morning without thinking too much about it. After doing so, I checked my program that uses the camera to see if it was running properly. I’ve got an Arducam64mp camera that I’m using on that machine, and often when the kernel gets updated I need to reinstall the kernel drivers from Arducam. They have a script, so normally it runs easily enough.

wim@WimPi4-Dev:~ $ sudo ./install_pivariety_pkgs.sh -p 64mp_pi_hawk_eye_kernel_driver
Hardware Revision: d03114
Kernel Version: 6.1.19-v8+
OS Codename: bullseye
ARCH: aarch64

--2023-03-21 10:36:25--  https://github.com/ArduCAM/Arducam-Pivariety-V4L2-Driver/releases/download/install_script/64mp_pi_hawk_eye_kernel_driver_links.txt
Resolving github.com (github.com)...
Connecting to github.com (github.com)||:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://objects.githubusercontent.com/github-production-release-asset-2e65be/353945933/a0487b40-ef2c-4923-b366-3e8d0b6f0c88?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20230321%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230321T173626Z&X-Amz-Expires=300&X-Amz-Signature=f28c85b9e602c3789a04e891e7a91d43a0dd89759e7297b888093b54fee6670d&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=353945933&response-content-disposition=attachment%3B%20filename%3D64mp_pi_hawk_eye_kernel_driver_links.txt&response-content-type=application%2Foctet-stream [following]
--2023-03-21 10:36:26--  https://objects.githubusercontent.com/github-production-release-asset-2e65be/353945933/a0487b40-ef2c-4923-b366-3e8d0b6f0c88?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20230321%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230321T173626Z&X-Amz-Expires=300&X-Amz-Signature=f28c85b9e602c3789a04e891e7a91d43a0dd89759e7297b888093b54fee6670d&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=353945933&response-content-disposition=attachment%3B%20filename%3D64mp_pi_hawk_eye_kernel_driver_links.txt&response-content-type=application%2Foctet-stream
Resolving objects.githubusercontent.com (objects.githubusercontent.com)...,,, ...
Connecting to objects.githubusercontent.com (objects.githubusercontent.com)||:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 11382 (11K) [application/octet-stream]
Saving to: ‘64mp_pi_hawk_eye_kernel_driver_links.txt’

64mp_pi_hawk_eye_kernel_driver_links.txt   100%[======================================================================================>]  11.12K  --.-KB/s    in 0.001s

2023-03-21 10:36:26 (15.6 MB/s) - ‘64mp_pi_hawk_eye_kernel_driver_links.txt’ saved [11382/11382]

Cannot find the corresponding package, please send the following information to support@arducam.com
Hardware Revision: d03114
Kernel Version: 6.1.19-v8+
Package: 64mp_pi_hawk_eye_kernel_driver -- bullseye-arm64-v5
You are using an unsupported kernel version, please install the official SD Card image(do not execute rpi-update):

wim@WimPi4-Dev:~ $ uname -a
Linux WimPi4-Dev 6.1.19-v8+ #1637 SMP PREEMPT Tue Mar 14 11:11:47 GMT 2023 aarch64 GNU/Linux

Today, it didn’t fix the problem. The script reports an unknown kernel version. I noticed that it’s reporting kernel version 6, which seemed unusual to me. That’s when I switched to my other Pi that I have most of my long term stuff running.

wim@WimPi4:~ $ uname -a
Linux WimPi4 5.15.84-v8+ #1613 SMP PREEMPT Thu Jan 5 12:03:08 GMT 2023 aarch64 GNU/Linux

A major bump in kernel version from 5 to 6 was unexpected. Now I’m left with the decision of either waiting to get the 64mp camera working with the new kernel or switching back to one of the PiCamera Model 3 units I have collected recently. Because this is on my development machine, the camera is less important to me than on some of my other units.

I attempted removing the special hooks for arducam to see if the 64mp driver had made it into the standard kernel source tree but no luck with that either.

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:

USPS Informed Delivery Daily Digest and Netflix DVDs

I use the USPS service Informed Delivery and highly recommend it. I get a daily email from USPS with a scanned picture of most of the mail that will arrive in my mailbox that day. Occasionally the email will say that there were items that could not be scanned, but it’s very useful since I don’t check my mailbox on a daily basis, but don’t want to have important items sit for extended times.

My mailbox is fairly secure, but I’ve also read that Informed Delivery has both good and bad features for people related to mail theft or identity theft.

I’ve been getting Netflix DVDs in the mail since 2000.  I’ve always been slightly fascinated with the efficiencies the post office and Netflix have worked out. If I take a DVD mailer to my local post office here in Seattle, Netflix recognizes it has been returned the next business day. If I drop a DVD at the local post office on Tuesday, Netflix acknowledges it on Wednesday, and I’ve usually got the next DVD delivered Thursday.

Until recently the Netflix DVDs were scanned like all other mail.

2019-09-13 (3)

It appears to have changed at the beginning of September. Now there’s a pair of fixed images arriving with a link that will take you directly to Netflix.

2019-09-13 (2)

The new behavior isn’t bad since all the Netflix disk scans look very similar, but are interesting to note. I wouldn’t be surprised that the new full color image reduces bandwidth over individual scans along with added benefit of the link to Netflix.

exiftool to manage DJI media files

DJI Drones don’t seem to remember the image count between formats of a media card. This creates a problem for me when I’m trying to backup and maintain my images and video.

Because the dates are all correct in the media files, retrieved from GPS data, organizing the files by naming them based on the date works for me.

Using ExifTool by Phil Harvey is a great solution for pulling the metadata from the files and renaming the files.

The command line that I was initially using is:

exiftool "-FileName<${CreateDate}.$filetype" -d %Y%m%d-%H%M%S%%-c -ext mp4 -ext dng -ext jpg dji*

It’s problem is that it orphans the SRT subtitle files from my videos that I’d like to keep matching the video files.

I’ve tried this variation to do it in one step but it doesn’t work, because the SRT files get renamed as MP4 files.

exiftool -verbose "-FileName<${CreateDate}" -d %Y%m%d-%H%M%S%%-c.%%le -ext mp4 -ext dng -ext jpg dji* -srcfile %f.srt

If anyone has a suggestion for how to rename all the media files in one directory I’d appreciate it. Even running two commands in sequence would be fine.


I’ve figured out that running these two commands in sequence will get me the results I am looking for:

exiftool "-FileName<${CreateDate}" -d %Y%m%d-%H%M%S%%-c.srt -ext mp4 -srcfile %f.srt dji*
exiftool "-FileName<${CreateDate}" -d %Y%m%d-%H%M%S%%-c.%%le -ext mp4 -ext dng -ext jpg dji*

I’m still looking for a way of doing it in a single command that may leave less room for error, but this is working for now.

Lily Pond

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

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.

Royal Gorge

Royal Gorge

Royal Gorge (Grand Canyon of the Arkansas), Colorado, U. S. A.

“Oh! the power that piled these wonders
As the mountains took their stations;
As a great red belt rose upward in a glittering zone of fire.” — Ferguson.

The crowning wonder of Colorado is the world famed Royal Gorge. Its rock piled crags tower above the river at this point 2,600 feet. The narrow and broad gauge railroad running through the canon is one of the greatest pieces of railroad engineering ever accomplished.