Planet GNOME

It’s already a month since we were in Spain for GUADEC and I still haven’t gotten around to writing something, so before I completely forget here are a few quick impressions and photos!

Local-First

Similar to last year, my main focus was on local-first, since that’s what I’ve mostly been working on recently. Julian and I gave a talk about Reflection and the p2panda-gobject bindings, and more generally plans for making local-first sync part of the GNOME developer platform.

Julian showing off p2panda-gobject during the BoF on Sunday

We also had a local-first BoF to discuss system integration on Sunday, and a p2panda-goject workshop on Monday where we prototyped the Migrations app Jakub designed. Both were really well-attended, and it was super cool to see people starting to prototype their own little experiments that sync, including a collaborative Snake game, and a collaborative drawing app.

Blackboard at the local-first BoF with some notes on the Contacts and Sync portals

Our current thinking around system integration is that we wan to have two separate portals: one for Contacts, which would just manage P2P identities (so apps don’t have to each have their own identity system and contacts management), and a second one that actually syncs data on behalf of apps using a system API. For the former there is already a relatively detailed plan (see the talk linked above), and this will be prototyped as part of a p2panda NLnet grant.

This entire area is of course still experimental so all plans are subject to change, but it’s exciting to see things get more and more concrete over the past year.

Talks

Some of my favorite talks:

• Session Save/Restore by Adrian Vovk: Really cool to see the progress in this area, but also incredible how many moving parts are involved in getting this to just work. Kudos to Adrian and everyone else who’s helping to push this forward!
• Foundation Annual General Meeting by Allan Day: Really clear and concise overview of where the Foundation is at, what changes have been made to make it more financially sustainable, and what challenges still persist. The fellowship in particular is a very nice, tangible new thing and at least to me a sign that some things have changed for the better. I found this framing particularly interesting: the Foundation is a corporation, and the AGM is a meeting for “shareholders”, i.e. people who invest their time (rather than their money) in the Foundation, to assess whether the investment is well managed.
• The Future of Boxes by Felipe Borges: I’m very happy to see Boxes revived and modernized, it’s a secret gem of our app ecosystem. Kudos to Felipe for his work on this!
• A Brief History of Graphs by Sjoerd Stendahl: Very nice talk, and a great success story for how programs focused on the third-party app ecosystem like Circle can help to bring people into the community.
• GNOME OS Mobile lightning talk by Aberrahim Kitouni: Between this and the Mobile BoF it was very nice to see more people across the community pushing towards making mobile an official part of the GNOME release process.

Great to see new generations making old wisdoms their own :) City and Venue

The logistics of constantly going back and forth between the Rialta dorms, the University building, and the city center made the social side of the conference more difficult than in other years, especially because public transit stopped relatively early in the evening. As usual, the smart move would probably have been to stay in the city center, but that only goes so far if everyone else is staying at the official accommodation, which is far away. More generally, the A Coruña city center was cute, but other parts of the city felt really car-centric and not very fun to be in.

The view from the hill was pretty cool though :) Meta

I found it a bit sad that once again, we didn’t manage to use the fact that so many people were together in person to make progress on resolving the conflicts of the past few years. I didn’t see it as my responsibility to take care of this, and I assume everyone else felt the same way. But here’s an idea for next year: An official “Conflict Resolution BoF”, chaired by a trained mediator.

If there’s any interest I’d be happy to co-organize something like this, but I wouldn’t want to be solely responsible for it.

More Photos

Local-first workshop on Monday Philipp at the Design BoF The Mobile BoF People hacking at the university Traditional GUADEC dinner

See you next year!

Earlier this month, I published a post about the future of Boxes where I detailed the huge technical rewrite I have been doing, porting to GTK4, Libadwaita, and replacing our SPICE display widget with Libmks. Today, I want to share a structural decision that aligns with that vision and sets up the project for long-term health/sustainability.

I have formally submitted a proposal to remove Boxes from the core-developer-tools set in gnome-build-meta and transition it towards becoming an independent application (with the ultimate goal of applying for GNOME Circle once all criteria are met).

I want to dive into why I am making this move, what it means for users and maintainers, and why I believe this is the right path forward.

There is No Drama Here

First off, let’s get this out of the way: there is zero drama between Boxes and the GNOME project.

Boxes continues to be built by the same core set of contributors, fully committed to the GNOME Human Interface Guidelines (HIG) and deeply integrated into our ecosystem. We aren’t stepping away from GNOME. We are simply right-sizing how Boxes is categorized, distributed, and maintained.

Why Boxes Shouldn’t Be “Core” (and Why Versioning with the OS is Outdated)

The desktop Linux landscape is shifting toward image-based operating systems with atomic updates and immutability. In this model, the underlying operating system provides a slim, reliable base, while applications live on top and update independently at their own pace.

Tying a complex application like Boxes to the biannual GNOME release schedule is not useful anymore. It forces us to hold back features and bug fixes for months just to align with the OS cadence, when users should simply get updates when they are ready and stable.

Furthermore, virtualization isn’t an essential utility that needs to be pre-installed on every single user’s machine by default. Boxes fits much better as a targeted application users explicitly choose to install when they need it.

Flathub-First: Moving Fast and Ending Distribution Bottlenecks

As a maintainer, maintaining separate code paths and stable branches for dozens of traditional distribution packages is simply not sustainable long-term. I can no longer afford to maintain multiple stable branches. Moving forward, I am simplifying maintenance down to one stable branch and one development/nightly branch. To make this sustainable, Flathub is our primary and only officially supported distribution method.

By bundling the virtualization stack in our Flatpak, we ensure that users get a much more tested, consistent, and working virtualization backend regardless of what operating system they are running.

Moving out of Core allows us to heavily discourage downstreams from individually packaging Boxes. Instead, distros should defer their users to the official Flatpak on Flathub. If you are filing bug reports or seeking support, the Flathub build will be the baseline.

Branding and Infrastructure Changes

To reflect this independent status, a few logistical changes are happening alongside this move. We are dropping “GNOME” from the user-facing app branding. Going forward, it will simply be named “Boxes”,  and we will soon be moving to a new website domain (which is currently being finalized). Importantly, our Flatpak application ID will remain org.gnome.Boxes for full continuity and compatibility. This means existing installations, user settings, and Flatpak configurations won’t break, and users won’t need to reinstall anything.

What’s Next?

This change gives us the flexibility to release updates whenever features are ready, iterate faster, and dramatically reduce maintainer burnout, all while delivering a more reliable and consistent user experience via Flathub. Once we settle into this new cadence and finalize our transition, we plan to apply for GNOME Circle.

To set clear expectations on timing: since Boxes currently uses GTK3 in its stable releases, we will soon submit an application for GNOME Circle review following our GTK4/Libadwaita rewrite.

If the Circle application is approved before the GNOME 52 Alpha deadline, the plan is to proceed with the removal from core-developer-tools and transition to Circle in time for the GNOME 52 release in March 2027.

For distribution maintainers wondering about upcoming distro releases: distros targeting GNOME 51 can continue to package the GNOME 50 release of Boxes, which will remain supported for the standard lifecycle of that release. If everything goes according to plan, GNOME 52 won’t include Boxes in the core set anymore. At this point, please don’t package Boxes anymore.

Week 29

This week's icon is for Deimos Hall's project:
Metamorphosis: "Edit metadata"

Check out all weekly app icons created so far in the gallery and follow my icon creation adventures as they happen (including sketches) on the Fediverse.

Need icons?

I love designing icons and am happy to contribute them free of charge when your project is Free and Open Source. Funded by community sponsors (every little helps!).

Hello all! It’s my first blog ever, so please bear with me.

Recently I’ve been active in Engagement team and helping out with the reboot. Hopefully you noticed our social media accounts are a tad more lively!

Part of the reboot process was dropping all the unrelated activities the team accumulated over the years, like events and such, with the goal on focusing on social media purely. There’s still work to do, but since we started doing weekly meetings (Monday 16:00 CEST, if you’re interested please see our meeting pad!) progress has been steady.

But we need your help in this! Engagement team is quite small, and to properly expand our activities onto other social media we need more contributors. Do you know how to edit images, create graphics? We need YOU for Instagram! Do you know how to make videos (short form or long form)? Our YouTube and TikTok are waiting for you! And let’s not forget that we always welcome new ideas for posts or people sharing their posts on social media for us to boost.

Currently platforms we’re on include:
– Fediverse
– Bsky
– Reddit

We want to (potentially! nothing here is set in stone!) also expand on:
– Facebook
– TikTok
– Instagram
– Improve our LinkedIn
– Improve our YouTube

But this is currently out of reach for us due to not having enough volunteers. We welcome everyone who wants to make world think better about GNOME!

To help developers in reaching us we introduced new labels:

– Newsworthy, for when you want us to share something on social media
– Team: Engagement, for when you want to summon us to discuss something.

We also have an „Engagement Materials” label, when you have some assets for us to use.

Interested? Visit us in #engagement:gnome.org and #socials:gnome.org Matrix rooms.

Written by Victoria Niedzielska. Thanks to other Engagement team members for proofreading the blog post!

Comments welcome here.

Most of GNOME 51 is now packaged for Fedora 45. Starting today and running through the end of the week, we will be running our traditional Fedora Test Day for GNOME. If you are a Fedora user, you can help us find last-minute integration issues and iron out what’s going to become the stable Fedora 45 release.

You can either boot the latest Fedora 45 image (nightly) in a virtual machine or update an existing test setup. Follow our guided test matrix, try out different features, and record your results. Even testing for 15 minutes and reporting a single issue makes a huge difference.

Visit https://fedoraproject.org/wiki/Test_Day:2026-08-17_GNOME_51_Desktop for more info. You can join the Fedora Workstation Matrix chat channel if you have more questions.

I wholeheartedly dislike GMail (ethically, technically, and UX), and for my personal email I have always run my own server. But for work email I don’t have a choice. I am using isync/mbsync to make it usable for me and mutt. Until now I’ve used a Google app password to authenticate, but they are a security nightmare. OAuth2 is a better way. Sadly the interwebs have only scarce, outdated, or buggy recipes, so I finally spent the better part of an afternoon and moved OAuth2.

For the past few months, we’ve been developing all kinds of features for the future GIMP 3.4 release. We noticed recently that our changelog was getting quite long - a good problem to have!

While there’s been a lot going on internally, it’s been a while since we made a public progress report. So we want to share details on some of the new features and UX improvements that’ll be available in the first development release, GIMP 3.3.2. This won’t be an exhaustive list (we have to save at least some news for the release itself!) but hopefully it will give you some insight into the current direction and progress of GIMP’s development.

• New Project File Format
• MyPaint Brush: Spectral Blending
• Non-Destructive Editing
• PSD Support Improvements
• Native File Chooser Dialogs
• User Experience and Interface Updates
• Assorted Changes and Fixes
• What’s Next

New Project File Format¶

The big focus for maintainer Jehan recently has been developing a new project file format for GIMP.

XCF has been GIMP’s primary project format since 1997, and it has served many users well. Over time however, we’ve observed more and more limitations of the binary XCF format. Among other issues, it does not easily support very large or complex projects, such as the multi-page and animation features currently planned for GIMP 3.6.

The new project file format will follow a more common “zipped XML” structure. While the technical details are still being designed and implemented, this change will allow for faster saving since we’ll only need to update parts of the file instead of the whole thing each time. It will also set the stage for much desired features such as auto-saving, which will now be much more feasible.

That said, XCF is not going away! Backwards compatibility is important to us, and we will continue to support loading XCFs in all future versions of GIMP. (For instance, we’re quite proud that a XCF file made by a small company for their logo in 1998 still renders the same way in the latest version of GIMP)

However, going forward we will only add support for saving/loading new features in the new project file format once it is finalized.

MyPaint Brush: Spectral Blending¶

During GIMP 3.2’s development, we upgraded to a newer version of the MyPaint brush engine. While this brought new brushes and canvas interactions to the MyPaint Brush Tool, one feature that was left out was Spectral Blending.

Spectral Blending simulates the effects of blending physical pigments in digital art. For example, blending yellow and blue will produce a green color instead of darker yellow, and blending red and yellow will create an orange mix.

Fortunately, new contributor Cassidie Grogan picked up the slack and implemented this feature. There is now a Spectral Blending checkbox in the MyPaint Brush Tool Options. If checked, the new blending method is used. You can control the strength of the blending with the Pigment slider.

Demonstration of MyPaint Spectral Blending

In addition, maintainer Michael Natterer improved the MyPaint Brush preview code to display at their full size instead of 48x48 pixels. This fixes an issue where the previews appeared blurry on larger screens.

Non-Destructive Editing¶

Alx Sa has continued making updates to our non-destructive filter code. To list a few:

You can now apply filters non-destructively to Layer masks! To go along with this, the filter popover has been redesigned by Reju to show the active filters for both the layer and its mask, so you can interact with both on the same screen.

The Gradient Tool can now be used non-destructively! If you check Editable Gradient in the Tool Options, the gradient you create will be added to the filter stack like any other effect. You can toggle its visibility, rearrange its position in the filter stack and delete it. You can also edit the gradient, which will switch back to the Gradient Tool to let you make further changes.

User interface with a live Gradient filter on the layer, and a live filter on the layer mask

Filters without dialogs (such as Invert) can now be applied non-destructively on non-raster layers such as layer groups and link, text, and vector layers.

PSD Support Improvements¶

Normally we list all file format updates in a combined section, but there has been so much work done on PSD support (and by so many people) that we wanted to highlight it in more detail.

First, new contributor Frank Teklote has been busy improving our compatibility with PSDs. His big project for this release was creating a PSD metadata export procedure for TIFFs and JPEGs. This complements our existing PSD metadata import procedure, meaning that if you import a JPEG with paths or a TIFF with layers (or create one in GIMP), that information can now be retained in the exported image.

Another great thing about Frank’s work is that as we continue to improve our PSD compatibility, the TIFF and JPEG export features will automatically get those updates too!

Related to that, Jacob Boerema has implemented PSD Descriptor import support. Most of our current PSD support has been based on the public Adobe specification. This document was last updated in 2019 however, and modern PSDs use a relatively undocumented text format called Descriptors to store many features.

Now that GIMP can read descriptors, we’ve begun drastically improving our PSD import support. To list just a few updates: text layers are now editable, a number of adjustment layers and modern layer styles appear as their GEGL equivalents, and solid color shapes are imported as vector layers. This is an active area of development, including by two of our GSoC students Akascape and Waris Maqbool. We hope this work will make it easier for GIMP users to interact with existing PSD projects!

Editable PSD text layers in GIMP Native File Chooser Dialogs¶

We have always used the file chooser dialog provided by the GTK GUI library for people to find, load, and save files in GIMP. While the file chooser does the job, it often works differently than the “native” file chooser on non-GNOME platforms like Windows, macOS, and KDE. Additionally there have been some changes to the UI of this dialog in GTK3, which has inspired some strong feedback in our issue tracker!

Therefore, Alx Sa has begun porting GIMP’s file choosers to the “native” option provided in GTK3. This means that when you open or save a file, you will see your platform’s standard file chooser dialog instead of the GTK dialog (unless your platform uses that already, in which case there will be no change!)

Example of native file chooser on macOS, by Bruno Lopes

Many of the simple dialogs have already been converted. Those with more complex additional features will require some workflow redesigns, which we’re still developing.

User Experience and Interface Updates¶

A lot of new and existing contributors have submitted improvements to GIMP’s user interface and its user experience. We wanted to highlight their efforts, and encourage you all to continue sharing your feedback on our design issue tracker.

Designer Denis Rangelov has been hard at work updating GIMP’s UI icons. He recreated our layer lock icons to create a more consistent look.

He also took on the monumental task of converting all 78 of our cursor icons to SVG, which will allow us to scale them for higher resolution displays without losing quality!

Original Raster Cursor Denis’s Vector Cursor Example of original and vector cursors

There have been reported performance issues when drawing or zooming into the canvas when the canvas view was rotated. New contributor woot000 diagnosed the problem and created a fix. Now the “checkerboard” transparency pattern no longer rotates when the canvas does, which significantly boosts performance when painting or editing. They also fixed a related issue where the checkerboard pattern would disappear when zooming into the canvas past a certain point.

Gabriele Barbero implemented a redesign of the Search Action UI which was designed by Denis Rangelov. The new layout makes the associated shortcut key more visible, and is more consistent with the menu layouts.

Bruno Lopes has been working to fix issues with pop-up dialog displays on macOS. Since traditionally we have fewer macOS developers compared to other platforms, we’re really happy to see improvements for these users!

New contributor Andreas Vukman improved our Pattern dock display. Now smaller patterns tile to fill the available space, creating a consistent preview for all patterns instead of having some patterns display with odd amounts of padding. We think it makes the dock look much nicer!

Richard Gitschlag has updated the on-canvas text editor to allow selections when you Shift+Click in the text. It should now work similar to what you can do in a word processor like LibreOffice.

In previous versions of GIMP, you imported or exported metadata from the Metadata Editor by selecting an option in a dropdown. Ahmed E. Yassin has made this process more intuitive (and more consistent with the rest of GIMP’s UI) by replacing the dropdown with two buttons instead.

Ondřej Míchal reviewed several portions of GIMP’s UI and replaced many instances of the Spin Entry widget with Spin Scale. The Spin Entry widget is difficult to use when the width is shrunk, so this change improves usability in many areas of the UI.

Assorted Changes and Fixes¶

Our four GSoC interns have been continuing their work since the midpoint update. Recently, Waris Maqbool‘s Sharpen filter was merged into GEGL, so it’ll be available in the next GEGL release.

New contributor Dimitriy Ryazantcev has submitted several patches for improving our Windows ICO/CUR/ANI support. They’ve already fixed the rendering for certain 32bit ICO formats and made our loading and preview algorithms better match the Windows specification.

Estecka has fixed a rendering issue when applying NDE filters on passthrough layer groups, which made the image look different depending on whether the group had child layers or not.

New contributor Petr Vorel fixed a bug where pressing Alt+0 did not open the tenth most recent image in your history.

Lloyd Konneker, our main Script-fu contributor, fixed a regression in third party scripts where the number range for certain parameters wasn’t shown in the GUI.

Jacob Boerema and Alx Sa have responded to and patched a number of security reports about potential flaws in some of our image plug-ins.

What’s Next¶

There’s more in-progress work that we look forward to sharing with you all soon!

There is not an official 3.3.2 development release yet, as several roadmap items are still in-progress. If you’re feeling really adventurous and just can’t wait, you can try our “nightly” builds. Instructions are under the Automatic Development Builds header.

In the meantime, we are planning to release GIMP 3.2.6 in the coming weeks. It is a stable release so it won’t include many of the new features described here. However, it will have a number of important bug fixes and small improvements. We’ll discuss these more in the 3.2.6 release news post!

It’s been about a month since I started my Sovereign Tech Fellowship in mid-July, and I want to give you some updates about what’s been going on before I go on summer holiday for the next two weeks. The idea behind these update posts is to highlight certain aspects of my activities and get people interested in getting involved with design.

GUADEC 2026 This year I attended GUADEC in person for the first time and I really enjoyed it. There were three days of interesting talks followed by two days of productive workshops and hacking. My favorite talks were about:

• • the state of GNOME OS, an operating system that includes daily builds of all GNOME components, enabling us to identify system-level bugs before they reach distributions,
  • the new SVG renderer in GTK which enables scalable and animated icons,
  • the new symbolic icons themselves,
  • GNOME Shell design dreams, some of which are already materializing,
  • a new session save/restore framework that allows the user session and apps to save and restore their state across reboots which will enable system updates in the background without the user noticing the necessary reboot,
  • the path towards a Local-First Desktop, which highlights the potential of peer-to-peer synchronization for collaborative features in our app ecosystem,
  • the report on the journey of the Graphs app into GNOME Circle, our certification and education program for third party developers.

I gave a short update on the GNOME Design Team’s recent achievements and challenges, announced my fellowship and invited interested individuals to join us. Tobias and I lead the Design BoF where we discussed some recent design pattern standardization efforts and received helpful feedback from the audience. Furthermore, the discussions in between talks and workshops were an amazing opportunity to connect with other contributors.

I was not able to attend GUADEC in the past because of the locations, but also because of high travel costs. The GNOME Foundation provides travel sponsorships, and this year’s budget was not used completely. Please reach out to the Travel Committee if you are a contributor and need financial support to attend conferences and hackfests.

Kicking Things Off

Traveling to GUADEC marked the start of my fellowship, and the weeks after that I was pretty much busy with kicking off things of various kinds.

Internal

As an employee of the Sovereign Tech Agency, I went through the onboarding process, set up hardware and software tools, and got to know the team. The 2026 cohort of the Sovereign Tech Fellowship comprises 14 people from a variety of different projects, which provides an amazing opportunity to share knowledge and establish cross-project collaborations. I am responsible for organizing a monthly ‘Lightning Talks’ series, in which fellows give short presentations on topics of broader interest, with the intention of leading to longer peer mentoring sessions. For my own presentation, I chose to talk about This Week in GNOME, the GNOME project’s weekly blog that covers news from the community. I believe it is a major success because it enables our community members to share project news without having to set up their own blog. The numbers speak for themselves: a total of 2,643 news posts have been submitted by 335 individuals over a period of 261 weeks. I would like to take this opportunity to thank Felix Häcker for developing ‘This Week in GNOME’ and for curating a weekly post for more than four years.

Design

There are a few design patterns we have wanted to standardize for a while. These include Action Rows with a scale, time and date pickers, drag and drop target styling, and floating controls. I discussed with Alice which ones to prioritize and started with Action Rows with a scale. If your app uses a scale in an Action Row in a way that hasn’t been mentioned in the issue yet, please leave a comment with a screenshot. You are also welcome to contribute state-of-the-art examples from other platforms.

Another topic I plan to work on is the credentials portal and I’ve had a first video meeting with the maintainers of credentialsd to coordinate our timelines and clarify the requirements.

I also reviewed a few merge requests and provided some design feedback in issues and on Matrix. One topic I find particularly interesting and worth sharing is adjusting arbitrary colors to ensure contrast of the event widgets in Calendar. Other apps that have to handle arbitrary colors (e.g. user-selected colors) in the user interface might benefit from looking into using the oklab color space too. Alice has published a blog post about the CSS capabilities which helped me to figure out the proposal for Calendar.

Community

I’ll soon begin reviewing apps for GNOME Circle, and I’ve already had an onboarding meeting with Tobias from the Circle Committee and another interested contributor. My plan is to support new reviewers through peer reviews and feedback so they can gain experience in GNOME design.

I attended a video meeting about Test Center, a new app for installing experimental versions of apps and system components. It makes testing much easier, and I see some potential for newcomers to get involved through coordinated user testing.

Until now, I’ve never had the time to blog about my design work for GNOME, but I’ve finally set up this blog and have been really enjoying it so far. Since this is my first time blogging, I’d appreciate any feedback via Matrix.

Thanks for reading. I’ll be back in September after my holiday.

In our previous post we looked at fixing a super 8 film projector. While watching filme with a real projector has its own charm, it is inconvenient to say the least. First of all you make the entire room properly dark or you can't see anything. This is regardless of the fact that the projector bulb is consuming 100 watts of power to show the image. Even if you manage not to burn the film merely running it through the projector causes wear, scratches and tearing. While film typically ages very well, eventually it will turn into magenta goop or gets eaten by vinegar syndrome. Thus you'd really want to convert all these films into high quality digital files.

There are several companies that offer this service. If you only have a few rolls, using those is the smart thing to do. I, on the other hand, have so much material that using a commercial service would cost thousands (possibly tens of thousands) of euros. Fortunately, this is a fairly common problem and there are dozens of existing projects on the Internet to be inspired by. 

The main technical problem with super 8 film is that it is very small. A sequence of 10 super 8 images is approximately as long as a matchstick. The fact that projectors can display 18 frames per second with sub millimeter registration is an astounding achievement of mechanical engineering. How do they do that? Very difficultly.

Many of the DIY solutions start by taking an existing projector and modifying it to run slower. Then you remove the projection lens and aim a digital camera with a macro lens at the gate. This yields incredible results quality-wise but requires a fairly expensive macro lens and typically the modification on the projector is destructive. So that's out. Some more searching eventually lead me to this Github project.

The basic idea is simple. Instead of using a projector or trying to replicate a film transport (which proper tension and all that) instead rely on the basic stiffness on film and drive it directly with stepper motor. Film is not aligned mechanically but instead by detecting the sprocket hole with some straightforward machine vision code. Time to fire up the ol' 3D printer and order components. This is what the end result looks like after assembly

The thing at the top left that looks like a space cannon prop from a scifi movie is actually a microscope lens. Not only can it do > 1x optical magnification, it can do so at a cost of about 25 euros. The downside is noticeable chromatic aberration. The small flat thing on the other end is the Raspberry Pi HQ camera module that can do 4k at 12 bits per channel. The whole thing is run via a single Raspberry Pi 3 with a stepper motor hat. The board at the bottom is used to distribute 12V DC power to the lamp and motors.

Before going further, let's just spend some time appreciating just how awesome colors look in this film. Props to the chemical engineers at Kodak. And remember, the original image is about one third of the size of your smallest fingernail.

The Github repo says that you probably need to adapt the code to your setup. I basically ended up rewriting all of it from scratch. In the process I learned that OpenCV has its own GUI toolkit which is both simple (one could even say simplistic) and perfect for this use case. The first attempt took nine hours to process one 3.5 minute reel of film. Then I realized that trying to do 4k on material that physically maxes out at approximately 2k with the processing power of a potato is not a recipe for success. Halving the capture resolution and a few other optimizations brought the runtime down to about one hour per reel.

With this, some more custom software for image processing and stabilization coupled with FFmpeg scripts one can start to go through the archive of films. Doing so raises a fair bit of questions. For example:

Is that a 3 year old child driving a jury-rigged go-kart on a frozen lake on his own without even wearing a helmet?

Yes it is. A bit later a grown up drives the car but he is too heavy so the ice cracks under him. No one seems particularly concerned. This may seem strange to us but you have to understand that this was the very early 70s. The concept of safety had not been invented yet.