Category: Photography & Images

The Cycliq Fly6 has marginal resolution for license plates at anything other than lethally close distances and, after its recent battery failure and rebuild, I picked up an SJCAM M20 to see whether more dots would be useful.

The Fly6 records 1280×720 @ 30 fps, with somewhat high contrast and weird color balance:

It works better with a stationary target in good light:

The M20 records 1920×1080 @60 fps (among many other choices), with reasonable contrast and coloring:

Good lighting and no motion helps it along, too:

The original frames-grabbed-from-the-video aren’t visibly different from the JPGs you see here.

Collecting all the plates in one montage:

I enlarged the left pair by 200% and the right pair by 300%, using GIMP’s cubic interpolation, to make them large enough to see with the naked eye. The interpolation algorithm slightly smooths the edges, but the cameras put those weird compression artifacts / blobs in the original images.

The left pair also got auto-brightness adjustments to drag ’em out of the murk.

I saved the montage as a PNG, rather than a JPG, although JPG image compression made no difference.

All in all, the M20 has better image quality than the Fly6, but its 1.5× higher resolution isn’t a slam-dunk win and, IMO, video compression has more effect than image resolution. The Fly6 has no compression controls and I’ve set all the M20 controls to as good as they can be.

Both those license plates sport NYS’s now-obsolete high-contrast blue-on-white color scheme: the current blue-on-gold NYS plates have much lower contrast. In this age of ubiquitous license plate reading and storing, I cannot explain why this was allowed to happen.

The Fly6, now equipped with a high-quality 18650 lithium cell, should have more hours of run time than I can measure this early in the season. Perhaps six hours, with its red blinky LED at full throttle, according to the doc.

The M20 lasted 72 minutes with a freshly charged battery, which means it didn’t quite survive the trip. Performing battery maintenance in the middle of a ride for groceries isn’t appealing; I should conjure an external 18650 battery pack for the thing.

An SJCAM M20 action camera includes the date and time in its file names, but the directory entries appear with the wrong timestamp:

sudo mount -o uid=ed /dev/sdc1 /mnt/part
ll -tr /mnt/part/DCIM/Photo/ | head
total 4.8G
drwxr-xr-x 4 ed root  16K Apr  8  2016 ../
drwxr-xr-x 2 ed root 144K Jan 25 18:52 ./
-rwxr-xr-x 1 ed root 3.8M Jan 26 05:08 2018_0126_100825_001.JPG*
-rwxr-xr-x 1 ed root 3.8M Jan 26 05:08 2018_0126_100830_002.JPG*

I’m in the Eastern US time zone, -5 hr from UTC.

By definition, FAT directory entries contain the “local time” when the file was created / changed. Because it cannot know which “local time” applies, the Linux VFAT filesystem treats the timestamp as UTC and adjusts it by -5 hr.

So the camera writes the directory timestamps properly. When mounted, Linux correctly (for a reasonable definition of correctly) regards them as UTC, knocks off five hours to match this time zone, and displays the result.

Alas, disabling the VFAT timestamp conversion has no effect:

sudo mount -o uid=ed,tz=UTC /dev/sdc1 /mnt/part
ll -tr /mnt/part/DCIM/Photo/ | head
total 4.8G
drwxr-xr-x 4 ed root  16K Apr  8  2016 ../
drwxr-xr-x 2 ed root 144K Jan 25 18:52 ./
-rwxr-xr-x 1 ed root 3.8M Jan 26 05:08 2018_0126_100825_001.JPG*
-rwxr-xr-x 1 ed root 3.8M Jan 26 05:08 2018_0126_100830_002.JPG*

I’m not sure why that doesn’t do anything; it doesn’t generate any error messages.

Although it seems like a reasonable thing, one cannot force a specific time zone with, say, tz=EST or tz=EDT or tz=UTC8 or whatever.

You can specify an offset in minutes:

sudo mount -o uid=ed,time_offset=$((-5*60)) /dev/sdc1 /mnt/part
ll -tr /mnt/part/DCIM/Photo/ | head
total 4.8G
drwxr-xr-x 4 ed root  16K Apr  8  2016 ../
drwxr-xr-x 2 ed root 144K Jan 25 23:52 ./
-rwxr-xr-x 1 ed root 3.8M Jan 26 10:08 2018_0126_100825_001.JPG*
-rwxr-xr-x 1 ed root 3.8M Jan 26 10:08 2018_0126_100830_002.JPG*

The time_offset value is subtracted from the directory timestamp, which means you’re feeding in the actual time offset from UTC, including whatever Daylight Saving Time offset may be in order.

So Linux takes the FAT timestamp, adds (subtracts a negative) 5 hr, and displays the result as my (now correct) local time.

I suppose I could set the camera to UTC, but then the camera’s on-screen and in-video timestamps would be off by four or five hours, depending on the season. So it goes.