This is the April 2023 update for Niepce. Between outages caused by an unseasonbly ice storm, squirrels chewing cable, I discovered how painful is being off the grid. This is not the excuse, just the events that lead to downtime and April not being very productive.

The importer moved a little bit forward. I tried to use the brand new "sort by date" importer tool, that is used to test and exercise the logic. The improved importer address a few long standing issues, including not using libgphoto2 for USB Mass Storage, including flash card readers. This was a shortcut I had taken and the result was suboptimal. The new approach is to use libgphoto2 to find the device, and then switch to pure filesystem operations. That was issue 26.

I picked up my camera which I haden't done much since the pandemic started. After a firmware upgrade on the Fujifilm X-T3 (it's a 4 year old model, and the firmware is from this year, unlike most smartphones), I notice a new feature that allow setting a picture as favourite. My first question was "how is it stored?". I put that on my list for later.

After taking some pictures of the newly bloomed spring flowers, I tried the importer. The new files cause a bug with metadata making the importer unable to determine the creation date ; I hit this when trying to sort these new pictures.

Metadata parsing

Metadata parsing relies on exempi2 and rexiv2. The former are the Rust bindings for Exempi, the latter are the Rust bindings for gexiv2 which is itself C bindings on top of exiv2 C++ API.

The algorithm work this way: try to load an XMP from a file, and if not, fallback on rexiv2. Given that Exempi isn't aware of raw files, it should always fallback, except it doesn't, and the XMP it finds only contains one value: Rating. I think I just answered the question as to where the camera store if the image is favourited or not: in an XMP packet in the raw file ; packet found by Exempi's packet scanner. So I need to fix the logic by making sure that camera raw files are always parsed by the rexiv2 fallback.

libopenraw

And looking at Fujifilm RAF files I ended up peeling the onion and improving support for parsing these. Things are a bit more robust.

I released libopenraw 0.3.5. One of the key changes is that the tarball vendor the Rust crates.

I also moved further along with the Rust port by resyncing camera support with the main branch and adding support for Minolta MRW that was left behind so far, bringing the same support between the C++ mainline and the Rust port. And this keep uncovering bugs in the C++ implementation.

User interface

To integrate everything, the UI needed to be adjusted. We can now tell the directory importer to copy on import. I also cleaned up a few leftovers from great ideas from a decade ago that no longer make sense.

In conclusion

There are so many things to do that I try to focus on specific tasks from the user standpoint and implement what is necessary to perform them, which often means working on a solid foundation to support it. But in the end, I still haven't run the importer successfully on these pictures.

Until next month...