Hub's wlog

Dev Log September 2025

2025-10-11T00:00:00+00:00

Not as much as I wanted to do was done in September.</p>

libopenraw</h2>
Extracting more of the calibration values for colour correction on DNG. Currently work on fixing the purple colour cast.</p>
Added Nikon ZR and EOS C50.</p>

ExifTool</h2>
Submitted some metadata updates to ExifTool. Because it nice to have, and also because libopenraw uses some of these autogenerated: I have a Perl script to generate Rust code from it (it used to do C++).</p>

Niepce</h2>
Finally merged the develop branch with all the import dialog work after having requested that it be removed from Damned Lies to not strain the translator is there is a long way to go before we can freeze the strings.</p>

Supporting cast</h2>
Among the number of packages I maintain / update on flathub, LightZone is a digital photo editing application written in Java^{1</a></sup>. Updating to the latest runtime 25.08 cause it to ignore
the HiDPI setting. It will honour GDK_SCALE</code> environment but this
isn't set. So I wrote the small command line too gdk-scale</code> to output
the value. See gdk-scale on
gitlab</a>. And another patch in
the wrapper script.</p>}
`HiDPI support remains a mess across the board. Fltk just recently gained support for it (it's used by a few audio plugins).</p>`
`^{1</sup> Don't try this at home.</p> </div>}`



Dev Log August 2025
2025-09-07T00:00:00+00:00
Some of the stuff I did in August.</p>
AbiWord</h2>
More memory leaks fixing.</p>
gudev-rs</h2>
Updated gudev-rs to the latest glib-rs, as a requirement to port any
code using it to the latest glib-rs.</p>
libopenraw</h2>
A minor fix so that it can be used to thumbnail JPEG file extracting the
preview.</p>
Released alpha.12.</p>
Converted the x-trans interpolation to use floats. Also removed a few
unnecessary unsafe blocks.</p>
Niepce</h2>
A lot of work on the importer. Finally finished that UI bit I had in
progress of a while and all the downfall with it. It is in the
develop</code> branch which mean it will be merged to main</code>. The includes
some UI layout changes to the dialog.</p>
Then I fixed the camera importer that was assuming everyone followed
the DCIM specification (narrator: no they didn't). This mean it was
broken on iPhone 14 and the Fujifilm X-T3 that has two card slot
(really, use a card reader if the camera uses memory cards). Also sped
it up, it's still really slow.</p>
Also better handle the asynchronous tasks running on a thread like the
thumbnailing or camera import list content. I'm almost ready to move
on.</p>
Tore up code using gdkpixbuf for many reasons. It's incompatible with
multiple threads, gdk texture were already created from raw
buffers. This simplify a lot of things.</p>


Dev Log July 2025
2025-08-01T00:00:00+00:00
AbiWord</h2>
Working on rebasing and finishing an "old" patch from Michael Gorse
that implement accessibility in AbiWord. While the patch is a few
years old, it's perfectly rebasable.</p>
Pushed a lot of code modernisation on master, as well as various
memory leaks and crashes on stable.</p>
Released 3.0.7 (tag, and flatpak build). 3.0.8 might come soon as I'm
backporting more crashers that are already fixed on master. Until I
have a 3.1.90 version ready for testing.</p>
libopenraw</h2>
Finally I have Fujifilm X-Trans demosaicking, which needs more work as
it is still a crude port of the dcraw C code. A also apply the white
balance. Added few new cameras and some benchmarks.</p>
Finally I released 0.4.0-alpha.11.</p>
Also I did update libopenraw-view which is my GUI for testing
libopenraw. It now renders asynchronously.</p>
Supporting cast</h2>
Some other various stuff.</p>
glycin</h3>
The merge request to update
libopenraw</a>
was merged. Thanks to Sophie!</p>
gegl-rs</h3>
Updated gegl-rs to the new glib-rs.</p>
lrcat-extractor</h3>
Released a new version after updating rusqlite.</p>
Niepce</h2>
Ported to the latest gtk4-rs, hence the update to gegl-rs. Some small
API changes in the object subclassing needed to be handled.</p>


Dev Log June 2025
2025-07-02T00:00:00+00:00
May and June in one convenient location.</p>
libopenraw</h2>
Released 0.4.0.alpha10</p>
After that, added Nikon Z5 II and P1100, Sony 6400A and RX100M7A,
Panasonic S1II and S1IIE, DJI Mavic 3 Pro Cinema (support for Nikon
and Sony mostly incomplete, so is Panasonic decompression), Fujifilm
X-E5 and OM Systems OM-5 II.</p>
gnome-raw-thumbnailer</h2>
Updated to the latest libopenraw.</p>
Released 48.0</p>
flathub-cli</h2>
This is a project I started a while ago but put on the back burner due
to scheduling conflict. It's a command line tool to integrate all the
tasks of maintaining flatpak packages for flathub. Some stuff isn't
flathub specific though. I already have a bunch of
scripts</a> I use, and this
is meant to be next level. It also merges into it my previous tool,
flatpak-manifest-generator</a>,
an interactive tool to generate flatpak manifests.</p>
One thing I had left in progress and did finish implementing at least
the basics is the cleanup</code> command to purge downloads. The rationale
is that when you update a package manifest, you change the
sources. But the old ones that have been downloaded are still
kept. The cleanup downloads</code> command will find these unused sources
and delete them for you. I really needed this.</p>
flathub-cli is written in Rust.</p>
AbiWord</h2>
Fixing some annoying bugs (regressions) in master, some memory leakage
in both stable and master, a lot of in the Gtk UI code. I also fixed a
crash when editing lists in 3.0.6 that was due to some code not
touched since 2004, and even then that part is probably even
older. The short story is that updating a value in the StringMap<></code>
updated the key whose pointer ended up being help somewhere else. Yep,
dangling pointer. The fix was to not update the key if it is the same.</p>
On master only, I also started fixing the antiquated C++ syntax. For
some reason in C++ there was a lot of typedef enum</code> and typedef struct</code>, probably an artifact of the late 90's code origin.  At the
same time moved to #pragma once</code> for header includes. Let the compiler
handle it. Also fixed a crash with saving a document with revisions.</p>


Friday links 27 June 2025
2025-06-27T00:00:00+00:00
Some links for technical articles on various topics I read.</p>
std::mem is... interesting</a> -
Explore some of the functionalities in the std::mem</code> module of the Rust
standard library.</p>
How much code does that proc macro
generate?</a> -
Nicholas Nethercote tells us how you can answer this question with new
tooling in the Rust toolchain.</p>
PNG is back</a> - A
quick overview of the PNG spec 3. Spoiler: Animated PNG, HDR support
and Exif support.</p>
JavaScript broke the web (and called it
progress)</a> -
How the JavaScript ecosystem is over complicated for no reason with
only making the user facing stuff worse.</p>
QtWayland 6.6 Brings Robustness Through Compositor
Handoffs</a> -
Improvements in Wayland support in Qt 6.6, brought to kwin (KDE
compositor), fixing some stuff that Wayland should better at than X11,
but ended up being worse.</p>
jemalloc
Postmortem</a> -
jemalloc from its inception to the end.</p>


Dev Log April 2025
2025-05-03T00:00:00+00:00
April was light.</p>
exempi</h1>
Released Exempi
2.6.6</a> to fix
security issues from upstream.</p>
libopenraw</h1>
Some minor fixes in the thumbnail extraction, with JXL support and
locate larger Panasonic previews. Extract the exposure bias for
Fuijfilm files. Added the latest Canon cameras (still the support of
CR3 is work in progress).</p>
Released alpha.10 on May 1st.</p>


Friday links 2 May 2025
2025-05-02T00:00:00+00:00
Some links for technical articles on various topics I read.</p>
The Defer Technical Specification: It Is
Time</a></strong> -
Explains the proposal for the next C language standard for defer</code>.</p>
A guide to implement ActivityPub in a static site (or any
website)</a></strong> -
A guide to implement ActivityPub in a static website.</p>
20 years of git</a></strong> -
An history of git and its early days.</p>
Celebrating Git's 20th anniversary with creator Linus
Torvalds</a></strong> -
An interview with Linus Torvalds on the 20 years of git.</p>
I use Zip Bombs to Protect my
Server</a></strong> - A technique
of serving compressed zeros that a lot of bots don't handle properly.</p>
6 usability improvements in GCC
15</a></strong> -
New in a GCC 15 near you, better error messages.</p>


Dev Log March 2025
2025-04-02T00:00:00+00:00
A long overdue dev log. The last one was for September 2024. That's half a
year.</p>
libopenraw</h1>
Released 0.4.0-alpha9 of the Rust crate. Added a bunch of
cameras. Fixed some Maker Note for some Fujifilm camera, and a fews
other, also fixed some thumbnailing.</p>
The main API is now faillible with Result<></code> returned. This should
reduce the amount of panics (it shouldn't panic).</p>
Added support for user crops in Fujifilm files as I added support for
the GFX 100RF (sight unseen).</p>
Niepce</h1>
Changed the catalog format. By changed, it's just that it has an
extension .npcat</code> and that it is standalone instead of being a
folder. The thumbnail cache will be in the same folder next to it.</p>
Now we can open a different catalog. Also renamed some bits internally
to be consistent with the naming.</p>
Removed some UI CSS hacks now that the is an API for
Gtk.TreeExpander.set_hide_expander()</code> in Gtk 4.10. Fixed some bug
with the treeview not being updated. Removed Gtk.ColorButton</code>
(deprecated). Fix some selection issues with the Gtk.ListView</code>.</p>
Moved to Rust 2024.</p>
Added video thumbnailing. Code was inspired from Totem's.</p>
Fixed some bugs with importing hierarchies of folders, and fix
deleting a folder with folders.</p>
Still working on the import feature I mentionned previously. It is
getting there. My biggest issue that one can't select a Gtk.ListView
item by item, only by index, which is complicated on a tree view. On
the other hand several of the fixes mentionned above came from this
work as I cherry-picked the patches to the main branch.</p>
i18n-format</h1>
Fixed</a> my
i18n-format crate</a> as the minor
version of gettext</code> removed the essential feature I was relying
on. Yes this is a semver breakage. I ended up having to split the
crate to have a non macro crate. From a usage standpoint it works the
same.</p>
The long term is to have this crate be unnecessary.</p>
Other</h1>
Other stuff I contributed to.</p>
Glycin</h2>
Submitted</a>
support for the rotation of camera raw files, and the Loupe
counterpart</a>.
This is a followup to the camera raw file support in glycin.</p>


Friday links March 21st 2025
2025-03-21T00:00:00+00:00
Some links for technical articles on various topics I read.</p>
NVIDIA emulation journey, part 1: RIVA 128 / NV3 architecture
history and basic
overview</a></strong> - From
the developers of 86Box emulators, some history and technical summary
about the first successful 3D GPU from Nvidia.</p>
zlib-rs is faster than
C</a></strong> -
Something on the reimplementation of zlib in Rust, and how it performs
better. Safe + speed, pick 2.</p>
Understanding
ActivityPub</a></strong>
Part 1 to 4. - A four part explainer on how ActivityPub, the protocol
behind the Fediverse, works.</p>
Memory safety for web
fonts</a></strong> -
Chrome developers explain how they are replacing freetype to a memory
safe solution, written in Rust, called Skrifa.</p>
GIMP 3.0
released</a></strong> -
Aleksandr Prokudin summarize what's new in the long awaited GIMP 3.0.
Don't forget his weekly
writeups</a> of Libre Arts
updates.</p>


Dev Log September 2024
2024-10-09T00:00:00+00:00
A long overdue dev log. The last one was for September 2023. That's a
year. Stuff in life has happened.</p>
Compiano</h1>
In November I switched Compiano to use pipewire directly for
sound. This mean removing bits of UI too.</p>
I should look at a release, but I have a few blockers I need to
tackle. One key element is that there is a mechanism to download the
soundbanks and for now it doesn't ask consent to do so. I don't want a
release without this.</p>
Raw thumbnailer</h1>
I already posted about it</a>.</p>
libopenraw</h1>
Lot has happened on that front. I want it to be a foundation of Niepce
and others.</p>
First adding it to glycin triggered an alpha release on
crates.io. There started a long cycle of alpha release, we are at
alpha 8 as of now. Various changes:</p>

Added the mp4parse crate directly as a module. A key reason is that
I already used a fork so it complicate things. Maybe I should make
these few bits upstreamable and use upstream.</li>
Added a mime types API</li>
Save up a lot of RAM when doing colour interpolation: it's done in
place instead of allocating a new buffer. This is significant as
this is done using a 64-bit float per component.</li>
Fixed the rendering in many ways. The only thing it needs it to
apply the colour balance.</li>
Fixed unpack or decompression of Olympus and Fuji files.</li>
Got an external contribution: Panasonic
decompression</a>. This
made me fix the loading of uncompressed Panasonic raw too. The more
recent Panasonic cameras are still failing though, there is a subtle
variant that needs to be handled.</li>
</ul>
Still missing from rendering: recent Nikon and all their exotic
variants and compression scheme, Canon CR3, GoPro, Sony.</p>
Niepce</h1>
Not so much work directly done on Niepce in the last few month, but
still.</p>
Ongoing features</h2>
Started a while ago some work towards the import and a rework of the
catalog (the main data storage).</p>
The former is the implementation of a workflow that allow immporting
images into the catalog.</p>
The latter involve reworking the catalog to become a self contained
storage as a sqlite3 database. One step I already did was to use it to
store the catalog preferences instead of a separate file. This should
also include fixing the UI open, creating, switching.</p>
This big two things are user visible and are a stop forward what I
want to happen as an internal milestone. Then I can start pluging the
library import and maybe import my picture vault. A good starting
point towards managing the collection, but not really for photo
editing yet. Gotta make choices.</p>
Images</h2>
Implemented support for HEIF which is being adopted by camera
manufacturers.</p>
I updated the RT engine to 5.11 which came with RawTherapee 5.11. This
is still a soft work of the code base to use strip out Gtk3 and a more
recent version of glibmm. The latter patch might no longer be needed
as I have since removed gtkmm from Niepce.</p>
I also implemented the GEGL pipeline using
gegl-rs</a>, which I took
over to make it useful. At one I shall try to figure out how to write
a loader in Rust to use libopenraw with GEGL.</p>
Cleanups</h2>
The UI is slowly moving to use blueprint, and I removed all the
first-party C++ code outside of bindings, no more Gtkmm and Glibmm is
only here because RT engine needs it.</p>
Other</h1>
Stuff I contributed to.</p>
STF</h2>
I took part to the STF effort and worked on fixing issues with
the desktop portal. The big chunk of the work related to the USB
portal, taking over code by Georges that is itself based on code by
Ryan. It spreads through multiple component of the stack: flatpak,
xdg-desktop-portal, xdg-desktop-portal-gnome, libportal and ashpd.</p>
I also did a bunch of bug fixes, crashes, memory leaks, etc in
flatpak, flatpak-builder, and the rest of the stack.</p>
I also implemented issue
#1</a> for
flatpak-builder: easy renaming of MIME files and icons, and also
properly fixing the id</code> in the appstream file, a common problem in
flatpak.</p>
Glycin</h2>
Glycin is a sandboxed image loader. I did implement the raw camera
loader</a>
using libopenraw. It's written in Rust, so is libopenraw now. Thank
you Sophie for merging it.</p>
Poppler</h2>
Jeff was complaining about a file being super
slow</a>,
with sysprof flamegraph. That picked my curiosity and looked at
it. The peculiarity of the document is that it has 16000 pages and a
lot of cross references.</p>
This lead to two patches:</p>


The first
one</a>
is in 24.06. There was a loop, calling for the length of the
container at each iteration. Turns out this is protected by a mutex
and that's a lot of time spend for nothing since the value is
immutable. Call it once before the loop and voila.</p>
</li>

The other
one</a>,
merged for 24.09 change that loop to be a hash table lookup. The
problem is that it want to locate the page by object reference, but
iterate through the page list. Lots of ref and lots of a page mean
even more iterator. The more complex approach is when building the
page cache (it's done on demand), we build a reference to page index
map. And the slow code is no longer slow and almost disappear from
the flamegraphs.</p>
</li>
</ul>
This make Evince and Okular faster to open that document and any
presenting similar attribute: a lot of bookmarks.</p>


New raw thumbnailer
2024-09-22T00:00:00+00:00
I have resurrected my camera old raw thumbnailer so that I can browse
directories full of of camera raw images in Nautilus. This is version
47.0.1, because GNOME 47 is out.</p>
Like the old one, it uses libopenraw to extract the previews from the
raw files.</p>
But, it now supports more raw formats, and if needed will render the
raw image to generate a preview, like it has to for my old Ricoh GR
Digital II images (the one from 2007). This leverage libopenraw
0.4.0</a> (still in
alpha stage) that has been rewritten in Rust</a>.</p>
Sadly to get is in the hands of users the only good solution is a
distribution package. At the time of writing there is none, but I put
together smething that allowed me to build a package for Fedora 40 to
install on my big rig.</p>
If you feel like it you can download the source
code</a> from
GNOME, and the
repository</a> is
on GNOME gitlab.</p>
This is how it looks with Nautilus 46 with a bunch of images from my
old Olympus E-P1:</p>
</p>


Dev Log September 2023
2023-10-01T00:00:00+00:00
It's October 2023.</p>
Niepce</h2>
Really very little.</p>
Fixed a cosmetic issues with icons in the workspace. The short version
is that for symbolic icons to work, they must be in a "standard" path
even if they are loaded from resources.</p>
Also some minor dependency checks, etc.</p>
lrcat-extractor</h2>
lrcat-extractor</code></a> is
my Rust crate to export Lightroom™ catalogs. It's used in Niepce. Just
a few bits of maintenance, like replacing docopt</code> with clap</code> for the
dumper tool, and using thiserror</code>.</p>
aplib-extractor</h2>
aplib-extractor</code></a> is
the sibling of lrcat-extractor</code>, a crate to export Aperture™
libraries. This is actually the oldest and one of my first projects in
Rust, which really shows. I worked on adding missing features so that
I can implement the importer in Niepce, including listing the volumes.</p>
The reasoning in implementing the import is to help refine the data
model in Niepce to be able to handle the structure of an Aperture™
library as it offer organizational features that Ligthroom™
doesn't. This actually might lead to deeper changes in Niepce internal
design.</p>
Once the importer works, I will release the crate officially as I'll
know the API is sound.</p>
Dia on Gtk3</h2>
Two years after I started it, and mostly drop the ball, the GTK 3
port of Dia has been merged</a>.</p>
I also fixed a few other small issues, including some memory leaks.</p>


Dia with GTK 3
2023-09-24T00:00:00+00:00
If you are running Dia</a> from the
nigthly GNOME flatpak, the last update brought a big change: it is now
a GTK 3 app. The UI shouldn't be much different, just some cosmetic
adjustments due to theming and other like widget spacing. Also it now
work with Wayland and HiDPI.</p>
It is something I started over two years ago, and that for some reason
I left on the back burner. So I did a final push and many thanks to
Zander for reviewing and merging
it</a>. Now we
shall hunt for regression. I already have a fix for the touchpad
scrolling</a>.</p>
The version is numbered starting 0.98. So if it is Dia 0.98 or higher,
then it's GTK 3.</p>
There is still some more stuff to do. Fix a regression in the
navigator widget, build without deprecation post GTK 3.8, etc.</p>


Dev Log August 2023
2023-09-02T00:00:00+00:00
Didn't really do anything on Niepce in August, so no updates on that
front.  However I worked on a few other things.</p>
libopenraw</h2>
A lot of work done on it. See my other wlog
post</a>. The short version is that
I should look towards releasing 0.4.0 sometime soon.</p>
Since that last post, I have added a long standing to-do item: code to
generate test cases so I can run a non regression test suite on
existing files. However I get hit with flaws in the various XML serde
crates.</p>
AbiWord</h2>
Did some work on
AbiWord</a>. Nothing ground
breaking, but I have a goal to try to release the next 3.0.x with one
or two bug fixes (UI), and then what I call 3.next</em> (likely 3.2) that
will focus on internal changes (stability) and UI fixes (anything
back-portable to 3.0.x will get back-ported).</p>
Done</h3>

Some code cleanup.</li>
Removed the use of boost</code> in many places where the standard C++
library would work.</li>
Use C++17 more.</li>
Making the build system less recursive. It's less complex and should
be more parallel.</li>
Removed some Gtk3 construct that are deprecated in provision of a
future Gtk4 port.</li>
More removal of the legacy containers.</li>
Rewrote the toolbars to use plain buttons and a GtkBox</code> instead of
GtkToolItem</code>. The look is slightly different.</li>
Fixing some Gtk3 bug: the table creation widget was not behaving
properly. Will be on stable too (3.0.x)</li>
Fixing some bugs with styling. (also on 3.0.x)</li>
</ul>


libopenraw Rust with C API
2023-08-28T00:00:00+00:00
As I previously talked about</a>, I started
porting libopenraw</a> to Rust. It
is now in a state where it has more feature than the original.</p>
When I started writing this post, I didn't have 100% of the code Rust,
but since I have removed the last bit of C++, for which I had cut
corners to make sure to have a functional API for C.</p>
The only C++ code left is the various utilities and the C++ test suite
to validate.</p>
The goal</h2>
The goal of the Rust rewrite is to have the digital camera raw
parsing library written in Rust instead of C++, while still being
available with a C API.</p>
The goal of the updated C API is to be close to the original
API. However it's also a good time to do some breaking
changes. Notably most of the "objects" are now immutable.</p>
Rewrite</h2>
I did the rewrite in a branch, aiming to provide the same level of
functionality as the C++ code. One of the first step was to rewrite
the test suite to use the same data set. Doing so did allow verifying
the consistency in behaviour, a progressively implement all the
features and formats.</p>
The C++ code use inheritance a bit to override some of the behaviours
based on which file format it was. One of the thing most camera raw
file have in common is that they are mostly a TIFF file. However Rust
doesn't do object-oriented. It has traits that allow implementing some
level of polymorphism, but in that case the concept had to be
rethought a little bit.</p>
Benefits</h3>
This is where Rust shines.</p>
First there are a lot of things Rust, or the ecosystem around, did for
me. In C++ I had re-implemented a stream system to allow IO on buffers
and handling endianess. In Rust you can just read from a slice (a
fixed size array of data) with the Read</code> trait, and there are
built-in functions to read endian-specific values. I still have the
memory of trying to figure out which include to add depending on the
UNIX flavour, between Linux, macOS and the BSD.</p>
Second, the Debug</code> trait. Just derive Debug</code> (it's a simple macro)
and you can "print" an type like that, using string formats. In C++,
well, it's a lot of work. And on enum types it will print a human
readable value, ie the one you write in code.</p>
Third, the safety. A lot of the safety feature of Rust prevent
mistake. And at runtime, the bounds checking catch of a lot of things
too. Being required to use Option<></code> or Result<></code> to handle cases
where in C++ you'd get some null value.</p>
At that point, a few bugs I identified porting / rewriting the code
made their way to the 0.3.x series in C++.</p>
Drawbacks</h3>
libopenraw requires a Rust compiler (technically it already did, but I
know some packagers that did disable Rust1</a></sup>. This mean that non
current architecture might not be supported. To me it's not a big
issue, I target modern computers.</p>
Testing</h2>
As mentioned I rewrote the test suite with the same data set. This is
an essential part of making sure the features work as previously.</p>
I also rewrote ordiag</code> and the dumper ordumper</code>. The dumper allow
analyzing the structure of the file, and I didn't have this one in C++
(instead I had a more primitive exifdump</code>). The dumper is heavily
inspired from exifprobe</code></a>
that has served me well and that I forked. Really I can see the amount
of work I didn't need to do with Rust.</p>
To add to this I wrote
libopenraw-viewer</code></a>,
a small Rust application to view the content of camera raw files. This
allow much more easily to see the output. This has helped me to find
fundamental bugs in some of the parsing that led to some fixes
"upstream", namely into the C++ version (0.3.x branch). I should have
done that a long time ago. This also allow me to test the Rust API.</p>
C API adaptation</h2>
Last but not least I had to provide a C API. This allow using the
library.</p>
Rust to C ffi has limitations. You can basically pass numbers,
pointers, and eventually simple structures.</p>
The libopenraw API did return several types of "ref" which are just
pointers to opaque types. The idea was always to only have opaque
types through the API, which internally were C++ instances.</p>
One of the key change is that the only object that can be explicitly
be created with the API is ORRawFileRef</code>, because it's the entry
point. Very few need to be released, most are held by the containing
objects.</p>
Some other constraints of the C API directed some choices in the Rust
API.</p>

Raw files are no longer Box<></code> but Rc<></code> due to the need to retain
them for the iterator.2</a></sup></li>
Metadata::String()</code> contain a Vec<u8></code> instead of a String</code> to
allow for the NUL terminated strings in the C API. They are maybe
not NUL terminated but ASCII.</li>
</ul>
New features</h2>
Meanwhile I added a few new features:</p>

extracting the white balance on most files (saveral Nikon are not
yet handled).</li>
color converting from the camera space to sRGB on rendering.</li>
a multi stage processing pipeline.</li>
</ul>
This is still not enough to have a complete processing pipeline, but
it's a start. It's going towards the only two issue left in the issue
tracker. Not that I don't expect more but it's a nice goal post.</p>
Integration</h2>
I submitted a PR</a> for
Miniaturo</a> to use the Rust
version of the library. This is not ready to be merged, but this
actually allowed me to fix a few API bits. The new Rust API is
relatively close to the old API that was the Rust to C bindings.</p>
^1</sup>See issue
13</a></p>
</div>
^{2</sup>
This is likely to change when I make libopenraw
multi-thread compatible.</p>
</div>}


Niepce July 2023 updates
2023-08-01T00:00:00+00:00
This is the July 2023 update for Niepce.</p>
The importer</h1>
Where we left, the workspace tree view didn't display the hierarchy.</p>
First, I discovered bug in the SQL triggers for folder path update. I
was missing the AFTER</code> keyword to have it run after the update.</p>
Workspace</h2>
Second, I need to specify a parent when adding items to the model,
then locate the parent, add to it. The problem is that we get a list
of folders in some order (I can order by any of the SQL columns). The
problem is adding an item to a parent that is not yet int the
model. There are few ways to go about it.</p>

Sort the folder list in order of a flattened tree. To be fair my
SQL skills are not good enough, and I'm not even sure I can do that
in sqlite. This would solve most of the problems.</li>
Sort the folder list once received. But this might not always work.</li>
Handle the case in the model: add with a placeholder parent and
re-parent as needed when the parent is added.</li>
</ol>
For now I chose 3. The risk is that if the parent doesn't exist then
the tree will stay lingering. It's just the view though.</p>
Here is the result:</p>


Niepce June 2023 updates
2023-07-01T00:00:00+00:00
This is the June 2023 update for Niepce.</p>
The importer</h1>
Back where we left, still working on the import.</p>
It looks like there is more work than anticipated to be able to import
a tree a files.</p>


Life update
2023-06-30T00:00:00+00:00
If you are looking for a Software Engineer with strong skills in C,
C++, Rust and JavaScript, with a strong FLOSS background, I am
available to hire.</p>
My résumé</a></p>


Niepce May 2023 updates
2023-06-02T00:00:00+00:00
This is the May 2023 update for Niepce.</p>
Life comes at you fast. And hit hard. tl;dr not as much progress as I
wished: I had to put this project a bit more on the sideline.</p>
This will be a short update.</p>
The importer</h1>
Some small bits:</p>
Some fixing in the metadata processing on import, notably a better
handling of raw files. Turns out the previous logic broke getting
metadata from video files.</p>
Also fixing some rexiv2</code></a>
/ gexiv2-sys</code></a> bugs
that are mostly memory leaks.</p>
I am pondering directly binding Exiv2 now that 0.28 got rid of
auto_ptr<></code> that had been deprecated for over a decade. cxx</code> should
make this easier. This would automatically resolve the problem above,
and I don't need to bind all the API, just what I need.</p>
Forecast</h2>
To move forward the importer, I need to fix the recursive creation of
folders (it currently flatten them to a single level).</p>
Misc</h1>
There are always the other fixes.</p>
Fedora 38</h2>
I pulled the trigger and updated to Fedora 38. And Niepce failed to
build because of a bug with bindgen with clang
16</a>, that was
already fixed, triggered by libgphoto2-sys</code>. Submitted the PR for
the crate</a> and we
are good to go. The short version is that clang 16 sent different data
for anonymous enums, that bindgen 0.60 couldn't handle. But at that
bindgen 0.65 was fine.</p>
This is the reason why I always check into git the generated bindings
and update them as needed, instead of doing it at build time.</p>
Application ID</h2>
I have been using org.gnome.Niepce</code> as an application ID. While it is
hosted in the main namespace repositories (it was back in the days of
Subversion, to which I am thankful), Niepce is not a core
app. Policies with the GNOME project do not allow using that namespace
for non core apps. So I had a perform a global change rename. Not a
big deal, and it doesn't change anything for users since there is no
release. I just needed to get this out of the way.</p>
libopenraw</h2>
Pushed a bit on the Rust port to implement metadata extraction. This
is driven by the goal of not having three different libraries. Still
some parity gaps with the C++ code, but it's closing in. I hope to be
able to release 0.4.0 based on the Rust code.</p>
Thanks you for reading.</p>


Niepce April 2023 updates
2023-05-03T00:00:00+00:00
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.</p>
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</a>.</p>
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.</p>
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.</p>


Niepce March 2023 updates
2023-04-01T00:00:00+00:00
This is the March 2023 update for Niepce. This is not an April's fool,
and this is not the year I can announce a release on April's fool
day. Sorry about that.</p>
Continuing with the renderer / previewer cache.</p>
I had to move ncr</code> to Rust. I didn't port it all, but the
widget and the main API are now in a Rust crate npc-craw</code>, the
fourth one in the workspace. The goal of this crate is to provide the
interface to the rendering pipeline. Some of the work included moving
away from Cairo surface and using GdkTextures instead. The main
pipeline is still the original C++ code using GEGL, it's easier for me
to bind the C++ code than to write wrappers for GEGL.</p>
In the same way, I also ported most of the darkroom</em> module to
Rust. This module is the one that will allow the image editing and
currently only handle displaying the images.</p>
All of this was necessary to finish the render / previewer integration
and making it work asynchronously: the image rendering happen in the
background without freezing the UI. There are still some issues but it
on overall, it works well.</p>


Integrating the RawTherapee engine
2023-03-18T00:00:00+00:00
RawTherapee</a> is one of the two major open
source RAW photo processing applications, the other is Darktable.</p>
Can I leverage RawTherapee RAW processing code for use in Niepce? Yes
I can.</p>
So let's review of I did it.</p>


Niepce February 2023 updates
2023-03-02T00:00:00+00:00
This is the February 2023 update.</p>
Not as much direct progress as I wished.</p>
One big change is that now the binary is linked from Rust. And at the
same time the autotools buid system is gone. The latter came first, as
to not have to ignore it when doing the former.</p>
Several challenges presented themselves with linked the app from Rust.</p>

We have to invert the dependency. We'd build the Rust code as a
library, generate the headers for the cxx</code> bridge and then build
the C++ code, and link it.  Instead we generate the headers, build
the C++ code as libraries and then the Rust code.</li>
We have to figure some tricks: the Rust executable needs to link to
some system libraries called directly from the C++ code, and also
need to link to asan if needed.</li>
</ol>
Otherwise, for the two previous topics, namely the importer and the
previewer.</p>


Implementing i18n-format, a Rust procedural macro
2023-02-05T00:00:00+00:00
This will relate my short learning journey in implementing a
procedural macro in Rust: i18n-format</a>.</p>
The problem</h2>
Building Rust applications means having to deal with localization, ie
allowing the UI to be translated in other languages. This is a big
deal for users, and thanks to existing tooling, if you use gtk-rs and
if you use the rust-gtk-template</code></a> to boostrap
your project you should be all set. The GNOME community has an history
of caring about this and most of the infrastructure is here.</p>
However there is one sore point into this: gettext, the standard
package used to handle strings localization at runtime doesn't support
Rust. For some reason the patch to fix it is stuck in
review</a>.</p>
While it mostly works, the lack of support cause one thing: the
getttext!</code>  macro that allow the use of localized strings as format
is ignored by the xgettext</code> command used to extract and strings and
generate the PO template. It is the !</code>, a part of the macro
invocation syntax in Rust, that is the blocker. Another problem is
that in Rust, for safety reasons, you can only pass a string literal
to format!</code>, which is why gettext!</code>  exists in the first place.</p>
Until xgettext</code> is fixed, either these strings are missed in the
localization process, or you end up reimplementing it with less
flexibility. That's what some applications do.</p>
What if I implement a macro that would allow using a function syntax
and still use the macro underneath? Oh boy, that mean I need to
implement a procedural macro, something I have been
dreading because it looks like it has a steep learning curve. It's a
topic so complicated that it is glanced over by most books about
Rust. Turns out it wasn't that difficult, thanks to a great tooling.</p>
The idea is as follow: convince xgettext</code> to recognize the string. It
should look like a plain function, while we need to call a macro.</p>


Niepce January 2023 updates
2023-02-02T00:00:00+00:00
This is the January 2023 update.</p>
We start the year by a Rust implementation of the file import. It
landed very early as the final stretch of work in 2022.</p>
Then a lot of cleanups, removing no longer needed cxx</code> bindings and
no longer used C++ code. This also allow removing some "wrapper" type
used in the Rust code base.</p>
The other gphoto2-rs</code> patch has also been merged.</p>


i18n-format for Rust
2023-01-22T00:00:00+00:00
A quick announcement for
i18n-format</code></a>, a Rust crate
to help with string localization. While it's not GNOME specific as it
is only about gettext, I wrote it for GNOME applications.</p>
The goal is to allow the use of gettext!</code> and ngettext!</code> while
xgettext can still extract the strings.</p>
Simple use:</p>
use i18n_format::i18n_fmt;

let number = 1;
let s = i18n_fmt! {
    i18n_fmt("This is number {}, make it so !", number)
};
</code></pre>
In your po/meson.build</code>, make sure to have:</p>
i18n.gettext(gettext_package,
  args [
    '--keyword=i18n_fmt',
    '--keyword=i18n_nfmt:1,2'
  ],
  preset: 'glib')
</code></pre>
If you use the regular
gtk-rust-template</code></a>,
that's probably all that needs to happen.</p>
Don't forget to check the
documentation</a>, or
the code</a>.</p>


Introducing Toot That!
2023-01-03T00:00:00+00:00
Introducing Toot That!</em>.</p>
It's a small WebExtension (browser add-on) for Firefox.</p>
It's the successor of Tweet
That!</em></a> but for use with
Mastodon (the Fediverse).</p>
It allows posting a link to the current tab to your chosen Mastodon
instance. Only the server knows this is happening. The extension
doesn't send anything else.</p>
Install it as a Firefox
Add-ons</a>.</p>


Niepce December 2022 updates
2023-01-02T00:00:00+00:00
Happy new year !</p>
Here is some udpdate on Niepce work done in December 2022. Mostly changes
under the hood, but important ones to move forward with improving the
features. The short version: it feels great to remove C++ code.</p>


Niepce November 2022 updates
2022-12-02T00:00:00+00:00
Here are the updates in Niepce
development</a> for
November 2022.</p>
I'll try to bring these updates on a more regular basis. In case you
missed it, there was a May update</a>.</p>


Fall of releases
2022-10-22T00:00:00+00:00
A couple of Rust crate releases.</p>
Now that the new glib-rs (and gtk-rs) are out, it's time for an update
of gudev</code></a> Rust bindings using the
newer version of glib-rs</code>.</p>
At the same time I updated
midi-control</code></a> to use a newer
version of midir</code> to iron out a cargo audit</code> warning.</p>
Available from crates.io</a>.</p>


Introducing Compiano
2022-09-23T00:00:00+00:00
I previously introduced
Minuit</a>. Later
I got notified that there was also a music education application for
KDE named Minuet</a>. So it was natural to yield
the name. It's relatively easy to do when you haven't had a release.</p>
I decided to rename my application Compiano</em>, a portemanteau word for
Computer Piano</em>.</p>


RTKit, portals, and Pipewire
2022-08-12T00:00:00+00:00
Peeling an onion, or how a bug report in a flatpaked application
lead to fixes in three different part of the stack, but no change in
the application itself.</p>


Release day
2022-06-25T00:00:00+00:00
It's release day, sorta. Both libopenraw and Exempi got a new release
within two days. Here is what's up.</p>


Update on Niepce
2022-05-25T00:00:00+00:00
Here we go, when I started that
project</a> in 2006, I had plenty
of ideas. I still have, but everything else is in the way, including
me.</p>
Since there have been some amazing apps, like
RawTherapee</a>,
Darktable</a>, and possibly some other I
miss, apps fullfilling some of the uses I envisioned for Niepce back
then. Not to mention a few other apps that did just disappear ; that's
life, it's hard to find maintainers or keep being motivated.</p>


New Again
2022-05-24T00:00:00+00:00
Old is new again. Apparently my blog was broken following a PHP
upgrade on the server. tl;dr PHP 8 broke things and code had to be
changed. I don't do PHP so I had to guess (I can read it, patch it,
but it's a lot of tries).</p>
Anyway I decided to bite the bullet and use a generator. I use
Hugo</a> in other places, but I decided to try
Zola</a>. I the past I have used
Jekyll</a> but ended up having a bad experience
with the Ruby install. Hugo works fine, it's written in Go and end up
being properly packaged in Fedora. Zola (see a naming theme?) is
written in Rust and also well packaged. So it's 'Les Misérables' or
'La bête humaine'.</p>
Note that the old blog will stay in place, read only.</p>
This is my wlog: Web Log.</p>
More to come.</p>

Hub's wlog

Dev Log September 2025

libopenraw</h2> Extracting more of the calibration values for colour correction on DNG. Currently work on fixing the purple colour cast.</p> Added Nikon ZR and EOS C50.</p>

ExifTool</h2> Submitted some metadata updates to ExifTool. Because it nice to have, and also because libopenraw uses some of these autogenerated: I have a Perl script to generate Rust code from it (it used to do C++).</p>

Niepce</h2> Finally merged the develop branch with all the import dialog work after having requested that it be removed from Damned Lies to not strain the translator is there is a long way to go before we can freeze the strings.</p>

Dev Log August 2025

AbiWord</h2> More memory leaks fixing.</p>

gudev-rs</h2> Updated gudev-rs to the latest glib-rs, as a requirement to port any code using it to the latest glib-rs.</p>

libopenraw</h2> A minor fix so that it can be used to thumbnail JPEG file extracting the preview.</p> Released alpha.12.</p> Converted the x-trans interpolation to use floats. Also removed a few unnecessary unsafe blocks.</p>

Dev Log July 2025

Supporting cast</h2> Some other various stuff.</p>

lrcat-extractor</h3> Released a new version after updating rusqlite.</p>

Niepce</h2> Ported to the latest gtk4-rs, hence the update to gegl-rs. Some small API changes in the object subclassing needed to be handled.</p>

Dev Log June 2025

libopenraw</h2> Released 0.4.0.alpha10</p> After that, added Nikon Z5 II and P1100, Sony 6400A and RX100M7A, Panasonic S1II and S1IIE, DJI Mavic 3 Pro Cinema (support for Nikon and Sony mostly incomplete, so is Panasonic decompression), Fujifilm X-E5 and OM Systems OM-5 II.</p>

gnome-raw-thumbnailer</h2> Updated to the latest libopenraw.</p> Released 48.0</p>

Friday links 27 June 2025

Dev Log April 2025

Friday links 2 May 2025

Dev Log March 2025

Friday links March 21st 2025

Dev Log September 2024

Niepce</h1> Not so much work directly done on Niepce in the last few month, but still.</p>

Other</h1> Stuff I contributed to.</p>

New raw thumbnailer

Dev Log September 2023

Niepce</h2> Really very little.</p> Fixed a cosmetic issues with icons in the workspace. The short version is that for symbolic icons to work, they must be in a "standard" path even if they are loaded from resources.</p> Also some minor dependency checks, etc.</p>

Dia with GTK 3

Dev Log August 2023

libopenraw Rust with C API

New features</h2> Meanwhile I added a few new features:</p>

Niepce July 2023 updates

The importer</h1> Where we left, the workspace tree view didn't display the hierarchy.</p> First, I discovered bug in the SQL triggers for folder path update. I was missing the AFTER</code> keyword to have it run after the update.</p>

Niepce June 2023 updates

The importer</h1> Back where we left, still working on the import.</p> It looks like there is more work than anticipated to be able to import a tree a files.</p>

Life update

Niepce May 2023 updates

The importer</h1> Some small bits:</p> Some fixing in the metadata processing on import, notably a better handling of raw files. Turns out the previous logic broke getting metadata from video files.</p>

Misc</h1> There are always the other fixes.</p>

Niepce April 2023 updates

Niepce March 2023 updates

Integrating the RawTherapee engine

Niepce February 2023 updates

Implementing i18n-format, a Rust procedural macro

Niepce January 2023 updates

i18n-format for Rust

Introducing Toot That!

Niepce December 2022 updates

Niepce November 2022 updates

Fall of releases

Introducing Compiano

RTKit, portals, and Pipewire

Release day

Update on Niepce

New Again

libopenraw</h2>
Extracting more of the calibration values for colour correction on DNG. Currently work on fixing the purple colour cast.</p>
Added Nikon ZR and EOS C50.</p>

ExifTool</h2>
Submitted some metadata updates to ExifTool. Because it nice to have, and also because libopenraw uses some of these autogenerated: I have a Perl script to generate Rust code from it (it used to do C++).</p>

Niepce</h2>
Finally merged the develop branch with all the import dialog work after having requested that it be removed from Damned Lies to not strain the translator is there is a long way to go before we can freeze the strings.</p>

AbiWord</h2>
More memory leaks fixing.</p>

gudev-rs</h2>
Updated gudev-rs to the latest glib-rs, as a requirement to port any code using it to the latest glib-rs.</p>

libopenraw</h2>
A minor fix so that it can be used to thumbnail JPEG file extracting the preview.</p>
Released alpha.12.</p>
Converted the x-trans interpolation to use floats. Also removed a few unnecessary unsafe blocks.</p>

Supporting cast</h2>
Some other various stuff.</p>

lrcat-extractor</h3>
Released a new version after updating rusqlite.</p>

Niepce</h2>
Ported to the latest gtk4-rs, hence the update to gegl-rs. Some small API changes in the object subclassing needed to be handled.</p>

libopenraw</h2>
Released 0.4.0.alpha10</p>
After that, added Nikon Z5 II and P1100, Sony 6400A and RX100M7A, Panasonic S1II and S1IIE, DJI Mavic 3 Pro Cinema (support for Nikon and Sony mostly incomplete, so is Panasonic decompression), Fujifilm X-E5 and OM Systems OM-5 II.</p>

gnome-raw-thumbnailer</h2>
Updated to the latest libopenraw.</p>
Released 48.0</p>

Niepce</h1>
Not so much work directly done on Niepce in the last few month, but still.</p>

Other</h1>
Stuff I contributed to.</p>

Niepce</h2>
Really very little.</p>
Fixed a cosmetic issues with icons in the workspace. The short version is that for symbolic icons to work, they must be in a "standard" path even if they are loaded from resources.</p>
Also some minor dependency checks, etc.</p>

The importer</h1>
Where we left, the workspace tree view didn't display the hierarchy.</p>
First, I discovered bug in the SQL triggers for folder path update. I was missing the `AFTER</code> keyword to have it run after the update.</p>`

The importer</h1>
Back where we left, still working on the import.</p>
It looks like there is more work than anticipated to be able to import a tree a files.</p>

Misc</h1>
There are always the other fixes.</p>