The Smell of Molten Projects in the Morning

Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.

Category: Photography & Images

Taking & making images.

Snow Flow

The recent snowfall arrived on a stiff north wind layering it atop the garage roof and sculpting the corner:

Snow – roof wave

The retaining wall along the driveway accumulated a thick coat that gradually peeled off as the weather warmed:

Snow – wall wave A

The wave crashed to the driveway in slow motion:

Snow – wall wave B

It seems to rebound from the wall, even though we know it’s been there all along:

Snow – wall wave C

This winter has more snow in store for us, but so far it’s been more decorative than disastrous.

One difference between deep snow and strong hurricanes: not much looting after the snow stops falling…

2021-02-07

Photo Backdrop Clamp Pad Embiggening

We got a photo backdrop stand to hold Mary’s show-n-tell quilts during her quilting club meetings, but the clamps intended to hold the backdrop from the top bar don’t work quite the way one might expect. These photos snagged from the listing shows their intended use:

Emart Photo Backdrop - clamp examples — Emart Photo Backdrop – clamp examples

The clamp closes on the top bar with the jaws about 15 mm apart, so you must wrap the backdrop around the bar, thereby concealing the top few inches of whatever you intended to show. This doesn’t matter for a preprinted generic backdrop or a green screen, but quilt borders have interesting detail.

The clamps need thicker jaws, which I promptly conjured from the vasty digital deep:

Spring Clamp Pads - PS preview — Spring Clamp Pads – PS preview

The original jaws fit neatly into those recesses, atop a snippet of carpet tape to prevent them from wandering off:

Spring Clamp pads - detail — Spring Clamp pads – detail

They’re thick enough to meet in the middle and make the clamp’s serrated round-ish opening fit around the bar:

Spring Clamp pads - compared — Spring Clamp pads – compared

With a quilt in place, the clamps slide freely along the bar:

Spring Clamp pads - fit test — Spring Clamp pads – fit test

That’s a recreation based on actual events, mostly because erecting the stand wasn’t going to happen for one photo.

To level set your expectations, the “Convenient Carry Bag” is more of a wrap than a bag, without enough fabric to completely surround its contents:

I put all the clamps / hooks / doodads in a quart Ziploc baggie, which seemed like a better idea than letting them rattle around loose inside the wrap. The flimsy pair (!) of hook-n-loop straps don’t reach across the gap and, even extended with a few inches of double-sided Velcro, lack enough mojo to hold it closed against all the contents.

It’ll suffice for our simple needs, but …

The OpenSCAD source code as a GitHub Gist:

	// Clamp pads for Emart photo backdrop clamps
	// Ed Nisley KE4ZNU Jan 2021

	/* [Hidden] */

	ThreadThick = 0.25;
	ThreadWidth = 0.40;

	HoleWindage = 0.2;

	Protrusion = 0.1; // make holes end cleanly

	inch = 25.4;

	function IntegerMultiple(Size,Unit) = Unit * ceil(Size / Unit);

	module PolyCyl(Dia,Height,ForceSides=0) { // based on nophead's polyholes
	Sides = (ForceSides != 0) ? ForceSides : (ceil(Dia) + 2);
	FixDia = Dia / cos(180/Sides);
	cylinder(d=(FixDia + HoleWindage),h=Height,$fn=Sides);
	}

	//———————-
	// Dimensions

	OEMpad = [24.0,16.0,3.0]; // original pad

	Pad = [35.0,25.0,8.0 + OEMpad.z]; // pad extension

	PadOffset = [0,-3.0,0];

	CornerRad = 3.0; // corner rounding

	Gap = 3.0;

	//———————-
	// Shape the pad

	module BigPad() {

	difference() {

	hull()
	for (i=[-1,1],j=[-1,1],k=[-1,1])
	translate([i(Pad.x/2 – CornerRad),j(Pad.y/2 – CornerRad),k*(Pad.z/2 – CornerRad) + Pad.z/2])
	sphere(r=CornerRad,$fn=6);

	translate(PadOffset + [0,0,Pad.z – (OEMpad.z + Protrusion)/2])
	cube(OEMpad + [HoleWindage,HoleWindage,Protrusion],center=true);

	}

	}

	//———————-
	// Build a pair

	translate([0,(Pad.y + Gap)/2,0])
	BigPad();

	translate([0,-(Pad.y + Gap)/2,0])
	rotate(180)
	BigPad();

view raw Spring Clamp Pads.scad hosted with ❤ by GitHub

2021-01-28

Monthly Science: Batmax NP-BX1 Status

After powering my Sony HDR-AS30V helmet camera for nearly all of this year’s riding, the Batmax NP-BX1 lithium batteries still have roughly 90% of their original capacity:

Batmax NP-BX1 – 2020-11

Those are hot off the Official Batmax charger, which appears identical to other randomly named chargers available on Amazon.

They’re holding up much better after a riding season than the DOT-01 batteries I used two years ago:

Sony DOT-01 NP-BX1 – 2019-10-29

Empirically, they power the camera for about 75 minutes, barely enough for our typical rides. I should top off the battery sitting in the camera unused for a few days, although that hasn’t happened yet.

Of course, the Batmax NP-BX1 batteries I might order early next year for the new riding season have little relation to the ones you see here.

2020-12-01
Bicycling For The Fun of It All
Somewhere out there, you’ll find his video:

Photo Op – 2020-11-09 – 287

Everybody needs a reason to smile!

Bonus: enough vehicles to keep the signal at Burnett green.

In the unlikely event you were wondering, 287 is the frame number from the video-to-still conversion:
```
ffmpeg -ss 00:03:30 -i /mnt/video/AS30V/2020-11-09/MAH07624.mp4 -t 20 -f image2 -q 1 'Photo Op - 2020-11-09 - '%03d.jpg
```
All in all, a fine day for a ride …
2020-11-12
Raspberry Pi Camera vs. RTSP Streaming

It Would Be Nice to turn the various Raspberry Pi camera boxen around here into more-or-less full-automatic IP streaming cameras, perhaps using RTSP, so as to avoid having to start everything manually, then restart the machinery after a trivial interruption. I naively thought video streaming was a solved problem, especially on an RPi, particularly with an Official RPi Camera, given the number of solutions found by casual searching with the obvious keywords.

As far as I can tell, however, all of the recommended setups fail in glorious / amusing / tragic ways. Some failures may be due to old configurations no longer applicable to new software, but I’m nowhere near ~~expert~~ experienced enough to figure out what’s broken and how to fix anything in particular.

Doing RTSP evidently requires the live555.com Streaming Media libraries & test suite. Compiling requires adding -DNO_SSL=1 to the COMPILE_OPTS line in the Makefile, then letting it bake it for a while.

The v4l2rtspserver code fetches & cleanly compiles its version of the live555 code, then emits various buffer overflow errors while streaming; the partial buffers clearly show how the compression works on small blocks in successive lines. Increasing various buffer sizes from 60 kB to 100 kB to 300 kB had little effect. This may have to do with the stream’s encoding / compression methods / bit rates, none of which seem amenable to random futzing.

Another straightforward configuration compiled fine, but VLC failed to actually show the stream, perhaps due to differences between the old version of Raspbian (“Stretch”) and the new version of Raspberry Pi OS (“Buster”).

Running the RPi camera through the Video4Linux2 interface to create a /dev/video0 device seems to work, but controlling the camera’s exposure (and suchlike) with v4l2_ctl behaves erratically. Obvious effects, like rotation & flipping, work fine, but not the fine details along the lines of auto exposure and color modes.

Attempting to fire raspivid through cvlc to produce an RTSP stream required installing VLC on a headless Raspberry Pi, plus enough co-requisite packages to outfit world+dog+kitchenSink. After all the huffing & puffing wound down, the recommended VLC parameters failed to produce an output stream. The VLC doc regarding streaming is, to me, impenetrable, so I have no idea how to improve the situation; I assume RTSP streaming is possible, just not by me.

Whenever any of those lashups produced any video whatsoever, the images suffered from tens-of-seconds latency, dropped frames, out-of-order video updates, and generally poor behavior. Some maladies certainly came from the aforementioned inappropriate encoding / compression methods / bit rates.

The least horrible alternative seems to be some variation on the original theme of using raspivid to directly create a tcp stream or firing raspivid into netcat to the same effect, then re-encoding it on a beefier PC as needed. I’m sure systemd can automagically restart raspivid (or, surely, a script with all the parameters) after it shuts down.

So far, this has been an … unsatisfactory … experience, but now I can close a dozen browser tabs.

2020-10-31
Arducam Motorized Focus Camera: Depth of Field

According to the Arducam doc, their Motorized Focus Camera has a 54°×41° field of view, (roughly) equivalent to an old-school wide(-ish) angle 35 mm lens on a 35 mm still camera. For my simple purposes, the camera will be focused on objects within maybe 200 mm:

Arducam Motorized Focus Camera – desktop test range

The numeric keys are 6.36 mm = ¼ inch tall, the function keys are 5.3 mm tall, and the rows are 10 to 11 mm apart.

The focusing equation converting distance to lens DAC values depends critically on my crude measurements, so the focus distance accuracy isn’t spot on. Bonus: there’s plenty of room for discussion about where the zero origin should be, but given the tune-for-best-picture nature of focusing, it’s good enough.

I set the CANCEL legend at 50 mm and it’s in good focus with the lens set to that distance:

Arducam Motorized Focus Camera – 50 mm

Focusing at 55 mm sharpens the ON key legend, while the CANCEL legend remains reasonably crisp:

Arducam Motorized Focus Camera – 55 mm

Adding another 5 mm to focus at 60 mm near the front of the second row shows the DoF is maybe 15 mm total:

Arducam Motorized Focus Camera – 60 mm

Focusing at 65 mm, near the middle of the second row, softens the first and fourth rows. Both of the middle two rows seem OK, making the DoF about 20 mm overall:

Arducam Motorized Focus Camera – 65 mm

Jumping to 100 mm, near the top of the first function row:

Arducam Motorized Focus Camera – 100 mm

At 150 mm, about the top of the far row just under the display:

Arducam Motorized Focus Camera – 150 mm

I think 200 mm may be the far limit of useful detail for a 5 MP camera:

Arducam Motorized Focus Camera – 200 mm

At 300 mm the DoF includes the mug at 600 mm, but the calculator keyboard is uselessly fuzzy:

Arducam Motorized Focus Camera – 300 mm

At 500 mm, the mug becomes as crisp as it’ll get and the text on the box at 750 mm is entirely legible:

Arducam Motorized Focus Camera – 500 mm

At 1000 mm, which is basically the edge of the desk all this junk sits atop, the mug and text become slightly fuzzy, so the DoF doesn’t quite reach them:

Arducam Motorized Focus Camera – 1000 mm

I limited the focus range to 1500 mm, which doesn’t much change the results:

Arducam Motorized Focus Camera – 1500 mm

I could focus-stack a set of still images along the entire range to get one of those unnatural everything-in-focus pictures.

2020-10-22

Arducam Motorized Focus Camera: Rotary Encoder and Equation

Mashing rotary encoder reading together with the focus-distance-to-DAC equation produces well-behaved camera focusing.

First, set up another test range:

Arducam Motorized Focus Camera - desktop test range — Arducam Motorized Focus Camera – desktop test range

Run the test code:

# Simpleminded focusing test for
#  Arducam Motorized Focus Camera
# Gets events through evdev from rotary encoder knob

# Ed Nisley - KE4ZNU
# 2020-10-20

import sys
import math
import evdev
import smbus

# useful functions

def DAC_from_distance(dist):
    return math.trunc(256*(10.8 + 2180/dist))

# write DAC word to camera I2C bus device
#  and ignore the omnipresent error return

def write_lens_DAC(bus,addr,val):
    done = False
    while not done:
        try:
            bus.write_word_data(addr,val >> 8,val & 0xff)
        except OSError as e:
            if e.errno == 121:
#                print('OS remote error ignored')
                done = True
        except:
            print(sys.exc_info()[0],sys.exc_info()[1])
        else:
            print('Write with no error!')
            done = True

# set up focus distances

closest = 50            # mm
farthest = 500
nominal = 100           # default focus distance

foci = [n for n in range(closest,nominal,5)] \
     + [n for n in range(nominal,250,10)]  \
     + [n for n in range(250,1501,25)]

# compute DAC equivalents for each distance

foci_DAC = list(map(DAC_from_distance,foci))

focus_index = foci.index(nominal)

# set up the I2C bus

f = smbus.SMBus(0)
lens = 0x0c

# set up the encoder device handler
# requires rotary-encoder dtoverlay aimed at pins 20 & 21

d = evdev.InputDevice('/dev/input/by-path/platform-rotary@14-event')
print('Rotary encoder device: {}'.format(d.name))

# set initial focus

write_lens_DAC(f,lens,foci_DAC[focus_index])

# fetch I2C events and update the focus forever

for e in d.read_loop():
#    print('Event: {}'.format(e))

    if e.type == evdev.ecodes.EV_REL:
#        print('Rel: {}'.format(e.value))

        if (e.value > 0 and focus_index < len(foci) - 1) or (e.value < 0 and focus_index > 0):
            focus_index += e.value

        dist = foci[focus_index]
        dac = foci_DAC[focus_index]

        print('Distance: {:4d} mm DAC: {:5d} {:04x} i: {:3d}'.format(dist,dac,dac,focus_index))

        write_lens_DAC(f,lens,dac)

Because the knob produces increments of ±1, the code accumulates them into an index for the foci & foci_DAC lists, then sends the corresponding entry from the latter to the lens on every rotary encoder event.

And then It Just Works!

The camera powers up with the lens focused at infinity (or slightly beyond), but setting it to 100 mm seems more useful:

Arducam Motorized Focus Camera - 100 mm — Arducam Motorized Focus Camera – 100 mm

Turning the knob counterclockwise runs the focus inward to 50 mm:

Arducam Motorized Focus Camera - 50 mm — Arducam Motorized Focus Camera – 50 mm

Turning it clockwise cranks it outward to 1500 mm:

Arducam Motorized Focus Camera - 1500 mm — Arducam Motorized Focus Camera – 1500 mm

The mug is about 300 mm away, so the depth of field extends from there to infinity (and beyond).

It needs more work, but now it has excellent upside potential!

2020-10-21

Category: Photography & Images

Snow Flow

Photo Backdrop Clamp Pad Embiggening

Monthly Science: Batmax NP-BX1 Status

Bicycling For The Fun of It All

Raspberry Pi Camera vs. RTSP Streaming

Arducam Motorized Focus Camera: Depth of Field

Arducam Motorized Focus Camera: Rotary Encoder and Equation