Image of the Week
I was revisiting some old pictures and found this series of pictures shot in the MyZeil shopping mall.

I was revisiting some old pictures and found this series of pictures shot in the MyZeil shopping mall.

Recently I took up photography again. Or rather, I made more of a conscious effort to take pictures again, as opposed to snapping them. I have my existing image import pipeline, which copies the files from the devices to my central server into timestamped directories.
Recently I actually exhausted the storage of my mobile phone and that made me
realize that I want to run my photo import via rsync from abroad on my phone
instead of local-only copying via mounted drives.
Before the change, the program took all files in the DCIM directory and
copied them via an SMB mount to the central server:
DCIM/Camera directoriesDCIM/Camera/archive as a safety measure. I manually delete the archive/ directory from time to timeBut running the import on a gphoto2 mounted directory does not allow to move transferred files to the DCIM/archive directory.
This would be ameliorated by using rsync. but a more discerning approach is still needed since I might have renamed the target directories
on the central server in the meantime.
The new approach addresses these points
DCIM/Camera directoriesrsyncUsing rsync and always transferring / synchronizing all images makes the transfer resilient against network failures and partial transfers.
Looking at the already existing filenames on the target end also opens the door to reading calendar entries and creating the directories with their calendar entry outright, as I've decoupled the directory name from the image creation timestamp.
ssh remote targetMoving to rsync also enables backing up to a remote machine over ssh. To move the files into the appropriate locations, I also need to read remote directories.
I did not find an established module on CPAN for this. Filesys::Virtual::SSH is OKish, but I don't like the API
of Filesys::Virtual overall. I only needed a single routine to read a remote directory, so I wrote a very simple wrapper:
sub r_readdir($dir, $type="d") {
if( $dir =~ m!^ssh:(?<host>(\w+\@)?[^:]+):(?<path>.*)! ) {
my $p = $-{path}->[0];
my $cmd = "ssh '$-{host}->[0]' 'find \"$p\" -type $type'";
currently("Reading '$p'");
if($verbose) {
$printer->output_permanent($cmd);
}
return map { s!^\Q$p\E[/\\]?!!r }
split /\r?\n/,readpipe( $cmd );
} else {
opendir my $dh, $dir
or die "Can't read '$dir': $!";
return readdir($dh);
}
}
This allows me to keep all filtering local in perl, which is not efficient over the network but highly efficient in protecting me from needing to shell-escape all the commands.
I often end up with directories named 20260417-1603 , which is better than
nothing. But I still would like to know what happened then. Often I have an
entry in my calendar which might be so-and-sos birthday party, or some
conference or whatnot, and having the computer automatically naming the
directory according to the calendar is a nice touch. I've put off this for a
long time, but now I've actually released
Net::CalDAV::FindEntry
to make this convenient:
my @relevant_events = $cal->get_events(
after => $image_timestamp,
before => $image_timestamp,
calendar => 'Corion'
);
# We blindly take the event that started closest before the photo was taken
my ($ev) = sort { $a->{start} cmp $b->{start} } @relevant_events;
if( $ev ) {
$target_directory{ $image } //= "$image_timestamp - $ev->{title}";
}
With that line added, I get conveniently pre-named directory names on the central server. It's still not perfect, as the directory naming needs to respect timezones while the image timestamps are either in a floating timezone or GMT, but this gets me a long step forward in convenience. Also, I need to clean up the titles of the calendar entries to make them suitable as directory names. Originally I thought Text::CleanFragment would be good for this, but it replaces spaces with underscores, which I do not want in the directory names, so I wrote a small ad-hoc sanitizer for that. So there still is work to do in the future.
Link: https://pivot-to-ai.com/
What Web3 is going great is for Crypto(currency) stuff, Pivot to AI is for AI-related grift.
Anthropic: Could AI be conscious? Pope Leo: lol, no
The Catholic Church has a number of obvious issues. But it’s not hard to do better ethically than an AI vendor.

This year I first used it for post-processing the videos for the German Perl Workshop. Usually
the videos only need some slight cutting or insertion of a simple overlay, which ffmpeg does well enough. This year,
I wanted to blank out some PII from a video, and having an interactive
non-linear editor was convenient here.
The program supports Linux, and it is a monster of an non-linear video editor. The free (as in beer) version can do everything I need, the paid version is cheap(ish) at € 300 (?) for a permanent license. The permanent license has more filters and some AI built-in, but I don't need that. Blackmagic Design make their money from selling hardware, and I also have one ATEM Mini Pro HDMI multiplexer.
The software is complex, but there are lots of Youtube videos showing how to find the relevant buttons. It took me half a day to find out how to overlay a video with black bars censoring some personal identifying information (PII) for our workshop videos. But in the process I also learned that even the free edition of Resolve can do automatic tracking of elements in a shaky-cam video.
For creating the filters, Resolve has the usual filter graph infinite canvas, which also takes some getting used to. But the automatic layout of the graph connections works well enough for me, and I'm not doing anything fancy like camera tracking or inserting dynamic video into other video.
I've used the software on my beefy Windows machine with an RTX 4090 and 128GB RAM, and editing and rendering a video on that machine is a breeze, even on a remote desktop connection from my main Linux desktop. On Debian, I didn't get it to run since it wants a newer version of the Nvidia drivers than Debian stable provides, and I didn't want to play around with mixing Debian stable and the Nvidia repositories.