Processing Proofs on a Raspberry Pi

All this hoo-ha about the single card slots on the new Nikon mirrorless cameras got me to thinking about real-time image offloading. Anyway, to skip over all the other ruminations I’ve had about the subject, I’m configuring a Raspberry Pi 3 to run img, my command line corollary to rawproc.

  • Downloaded the latest raspbian-lite image and installed.
  • Added a configure switch to rawproc, --disable-wxwidgets, so one can configure without having to find wxWidgets (hmm, that could be a solution to gtk3, --disable-gtk… just kidding)
  • Installed the -devs for libjpeg, libtiff, lcms2 , and libraw. Had to compile libpng and install to /usr/local, the raspbian version wasn’t new enough to do the exif.
  • Made a build directory, …/configure-ed into it, cd-ed to src/, and did make img, which just compiled the things needed to build img.

From the list, sounds easier that it was, I had to futz with libpng to find out the version thing, and I originally built libraw 0.19 but that threw out of memory exceptions and the raspbian version, 0.17, was new enough.

Anyway, here’s my processing revelation: I do 800x600 JPEG proofs of my daily/event shooting from the NEFs, stopped messing with full-sized JPEGs about a year ago. That and some work on a demosaic tool for a tutorial got me to thinking about how the “real” demosaic algorithms, AHD, AMAZE, and such, might be more than what I need for a smaller-than-original product. The “half” algorithm, dcraw -h, simply makes a single pixel out of a RGGB quad, no interpolation. So, I tried both, and not only was the downsized image virtually indistinguishable for both, I cut the processing time 75%. Here’s the half-size run, normal image size is 4948x3280:

./img /home/glenn/DSG_3111.NEF:half_size=1 blackwhitepoint resize:800 sharpen:1 DSG_3111.jpg
1: Loading file /home/glenn/DSG_3111.NEF half_size=1... No error
done. (4.287740sec)
Image size: 2474x1640
Normalizing image orientation from 1...done. (0.000004sec)
blackwhitepoint: ,7.00,121.00 (4 threads)... done (0.374611sec).
resize: 800x530,catmullrom (4 threads)... done (0.280587sec).
sharp: 1.00 (4 threads)... done (0.021484sec).
Saving file DSG_3111.jpg ... done. (0.044730sec)

About 5 seconds start-to-finish. Oh, that’s on a Raspberry Pi…

I very-very rarely use full-sized images anymore, most are for web posting and casual snapshot printing. So, I may just continue to use half demosaic…

My objective is to make a belt-clip device that is USB-connected to the camera; whenever I make an image, the Pi downloads a copy of the NEF, processes it to a proof, then copies it to a pre-built directory structure I can upload later to my website. Maybe later, scp the proofs to the website as i shoot them, that’d be cool…

Ruminations, food-for-thought…

2 Likes

Sounds like a great idea. I think @dmpop has done something similar awhile ago

Indeed, @dmpop has some wonderful things:

Little Backup Box

RPi Photo Server

1 Like

Pretty cool. I wonder how limiting the USB is…

It takes a couple of seconds for gphoto to download a 16MP image over usb 2.0. Fine for my use, could be problematic for 16’- image bursts from a D850. USB 3.0 is a lot faster, don’t know what cameras have it…

Hopefully the cameras skip usb3 and go for USB-C!