Little problem on the Mac, see this screenshot. Models and People are missing.
For this the macOS build currently requires Apple Silicon (M1 or newer): ONNX Runtime no longer ships an Intel-macOS library, so an Intel build would be missing the Models and People features.
Clear again, thanks.
Hi everyone,
Quick update: Thanks to the amazing testing and feedback here, FerrumPix has moved quickly over the weekend and we are now at v0.9.35!
Since Paul and Corey tested v0.9.32, Iâve focused heavily on fixing the reported issues, improving the performance, and adding some highly requested features.
Performance & Sliders (Addressing the sluggishness)
- Real-time Feedback: Sliders now redraw instantly on a smaller preview version while you drag, rendering at full size the split second you let go. No more lag or dropped changes!
- Faster Image Pipeline: Grain generation was completely rewritten to calculate by pixel position, eliminating the massive bottleneck that held up all other adjustment sliders.
- Smoother Scrolling: The gallery now caches and reuses UI tiles instead of forcing a full layout recalculation every time you scroll.
- Quicker Folder Loading: Opening folders is much faster now, as it only queries the pictures it is about to show.
Whatâs New & Fixed
- The History Tab is here: As requested, the layers panel now has a second tab listing every step youâve taken (Exposure, Crop, Mask, etc.) down to the exact slider name, allowing you to jump back and forth in your current session.
- One Drag, One Step: A long drag on a slider now writes exactly one history step when you let go, making
CTRL+Zbehave properly instead of leaving a pile of identical rows. - Wacom & Input Tweaks: The slider-sticking glitches should be gone. Also, sliders, curves, and brush strokes now safely end the moment the pointer moves with no button held.
- Trackpad Mode: Added a dedicated toggle below the tablet setting. When enabled, two fingers zoom the Viewer/Editor, a horizontal swipe moves the filmstrip, and dragging a zoomed picture pans it.
- More Screen Space: The top window bar is now a third lower than before, giving your photos more room.
The latest packages (AppImage, Flatpak, DEB, RPM, Windows, macOS) are live on GitHub. If you had some lag with the sliders in the first test, please give v0.9.35 a spin!
1 Like
For a feature overview, please also visit the website https://ferrumpix.app
2 Likes
Hi everyone,
Quick follow-up: FerrumPix v0.9.36 is now available!
This release is mainly about improving the editing workflow and fixing several issues reported over the last few days.
Highlights
- Crop, Rotate & Straighten are now one Transform tool: Geometry is now stored as a sequence of editable steps, so earlier crops and transforms can be revisited instead of relying only on history.
- Better geometry handling: Straightening, perspective correction, resizing and canvas changes now preserve previous geometry properly, and objects move with the image when you straighten or correct perspective.
- Better keyword support: FerrumPix now also reads keywords stored directly inside images, not just sidecars. That means collections tagged in Lightroom, Bridge or Photoshop can be searched more reliably.
- Server-wide metadata import: Immich and Nextcloud can now fetch shot data and keywords for the whole server at once, so searches work even for photos you have never browsed before.
- Path improvements: Paths can now be converted directly into mask layers or editable text-on-path layers.
- More UI options: Accent colour strength can now be adjusted, and five additional interface languages were added.
Fixes
- Renaming or moving files/folders now keeps ratings, labels, keywords, people and thumbnails.
- Keywords added later in Lightroom or Bridge are picked up correctly.
- Immich search now properly includes focal length, lens and shutter speed.
- Nextcloud caches metadata more efficiently.
- Video playback and shutdown are more responsive, especially on macOS.
- Several smaller geometry, watermark and translation issues were fixed.
The latest packages for Linux, Windows and macOS are available on GitHub.
4 Likes
What Raw Engine are you using? & Is there a lens correction section I havenât been able to find it.
FerrumPix uses LibRaw as its RAW engine.
For lens correction: yes, itâs there, youâll find the Lens Correction section below the Tone Curve in the Adjustments panel.
1 Like
Hi,
I tried FP, but I think it doesnât support my camera (Canon R6III, the only colour in the cr3 is pink).
This seems to relate to libraw (R6III is not listed) - but my version of RawTherapee also uses libraw, and it worksâŠa little bit strange.
And - where can I add missing lens correction data?
I might have to wait a while, before I can test it further.
I (finally) tried FerrumPix today, on macOS. I tried it as a replacement for DigiKam, mostly for browsing my library of JPGs.
At first, I was a bit disappointed how slow it scrolled the gallery (Mac Studio M2 Max on a 4K screen), but once I increased the image size in the gallery, it was fast enough.
At this point, the program was a joy to use. I particularly like how spacebar previews the current picture in full screen mode, and how tidy the UI is.
I keep my pictures in a yearly/evently directory tree. For larger/longer events, I appreciated that pictures can be grouped by month. However, I found it a bit annoying that filtering 3, 4, and 5 star images requires three separate clicks, and that filters reset whenever you switch directories.
Lastly, I noticed that everything seemed strongly oversaturated. If I had to guess, itâs splatting my sRGB images unmodified onto my DP3 screens. I couldnât find any mention of color management in the settings. This makes it mostly unusable for me in its current form on macOS and DP3 screens.
However, thatâs not to distract from the fact that I found the program a joy to use. If the color management issue were fixed, Iâd probably use it a lot!
Hi, thanks for the report,
and you are right about the cause. The R6 Mark III is too new for LibRaw: even the current 0.22.2 has no entry for it, and the Windows build of FerrumPix ships 0.21.4. LibRaw can still unpack the CR3, but it has no colour matrix for that model, so the camera white balance gets applied without anything correcting it afterwards. That is the pink cast you see. RawTherapee only uses LibRaw for unpacking and carries its own camera data, which is why it does better here.
Could you send me one CR3 from that camera? Without a sample I cannot verify anything. It would also help to know which platform you are on, Windows, Linux or macOS, and on Linux which LibRaw version your distribution installs.
On lens correction data: at the moment the calibration data is built into the application and there is no place for you to add your own. The R6 Mark III is not in the collection either, so lens correction will not match for that body yet. I am looking at both points.
Hi,
Congrats on this project. I really like its idea and execution. I think it fills a significant gap on Linux, especially for photographers who want something between a traditional RAW developer and a full-featured image editor. The combination of RAW processing, layers, masks, retouching and AI tools is really promising.
I have a few questions though, mainly about pipeline and demosaicing:
What bit depth / numerical precision is used for RAW processing (RAW pipeline)? For example, after LibRaw decodes the RAW file, are the RGB values kept as 16-bit integers, 32-bit floating point, or another format during operations such as exposure, highlights/shadows, curves, HSL and color grading?
Which demosaicing algorithm does FerrumPix use? I would love to see an option to choose algo in RAW section of preferences (at least).
Cheers and keep up the great work!
Thanks, that is a very precise question.
Bit depth: LibRaw decodes RAW files as 16-bit linear data. The initial RAW processing happens there, then the image is converted once to the 8-bit working bitmap using ordered dithering.
The main point adjustments exposure, contrast, highlights/shadows, curves, HSL, colour grading, etc. are processed together in a floating-point pass, so they are not repeatedly quantised after every adjustment. Blur, sharpening and similar neighbourhood operations work on the 8-bit image.
So the short version is: the RAW stage is 16-bit, the editor itself is not a full 16-bit/float pipeline.
Demosaicing: FerrumPix currently uses LibRawâs default AHD demosaicing. I have also tested DCB, and making the demosaicing method selectable in the RAW preferences is high on my list.
1 Like
Thanks for your detailed report that helps.
Scrolling: You found a real limitation in the grouped view. Unlike the normal grid/list views, it currently canât fully reuse/virtualise its tiles because of the full-width group headers. Thatâs also why larger thumbnails improve performance: fewer tiles need to be created. For now, the plain grid view should scroll noticeably better.
Star filtering: Thatâs currently designed as a set rather than a threshold, so combinations like only 4 and 5 stars are possible. I agree that this makes the common â3 stars and aboveâ case unnecessarily click-heavy, though.
Filters resetting: Thatâs intentional at the moment, but your workflow is a good argument for making at least some filters session-wide instead of folder-specific.
Colour management: Your diagnosis is correct. FerrumPix converts tagged input images to sRGB and uses sRGB as its working space, but there is currently no display-profile conversion on output. On a wide-gamut Display P3 screen that can result in the oversaturation youâre seeing.
One thing that would help me: do only the photos look oversaturated, or does the FerrumPix UI itself accent colours, icons, etc. also look unusually saturated compared with other apps? I donât currently have a wide-gamut Mac display here to test this myself.
Thanks again for taking the time to test it, and for the kind words.
1 Like
To test this properly, I set my left screen to sRGB, and my right screen to DP3. Both screens are the same model (Asus PA27UCGE), are calibrated, and capable of 98% DP3. I set the left screen to sRGB both in macOS and the OSD.
If I move a Preview.app (Appleâs color managed image viewer) from one screen to the other, it looks the same. If I move FerrumPix between the screens, it looks much more saturated on the DP3 side, both in photo content and every UI element. Fun fact, the first thing I did when opening FerrumPix, when I didnât yet know about the color management issue, was lowering the Accent Color Strength, as it seemed too saturated. The only colors that stays consistent between the two sides are macOSâ âtraffic-lightâ Close/Minimize/Maximize window buttons.
By way of demonstration, hereâs a screenshot:
The left side is the sRGB screen, the right side the DP3 screen. Each screen shows a MacBeth color checker image both in FerrumPix and Preview.
MacOS apparently decided that the screenshot should be saved in the lesser color space of sRGB. Regardless, the colors were appropriately converted from DP3, which you can verify as all the patches on the color checkers match their RGB labels. Preview shows the correct colors left and right, FerrumPix shows the correct colors on the left, but significantly more saturated colors on the right, both on the image itself and the UI.
Thank you for going to that much trouble, that is an excellent test, and it answers the one thing I could not verify here.
Since the entire FerrumPix window changes saturation between the sRGB and P3 displays, not just the photos, this confirms that the problem is not in the image-processing path. FerrumPix is currently drawing sRGB values onto a surface that macOS does not know is sRGB, so on the P3 display those values are effectively interpreted in the display colour space. The traffic-light buttons stay correct because macOS draws those itself.
That also means converting only the photos would be the wrong fix. The correct solution is for the whole FerrumPix drawing surface to be tagged as sRGB, allowing macOS to perform the appropriate conversion for whatever display the window is currently on.
I have added an experimental option for this to v0.9.38 . Under Appearance there will be a switch that tells macOS that FerrumPix renders in sRGB. It is off by default and requires a restart.
There is one caveat: whether this works depends on the kind of native layer the UI toolkit creates on macOS. I do not have a wide-gamut Mac display here to verify it, so FerrumPix will log whether the colour space could actually be applied rather than silently failing.
If you are willing to try it once 0.9.38 is available, your two identical displays running sRGB and P3 are pretty much the perfect test setup for this.
Also, based on your other feedback, gallery filters now persist when moving between folders. The star filter will remain set-based for now, and the grouped-view scrolling issue needs a more substantial layout change.
1 Like
Will do! Is there a ready-built release available for it, or do I need to compile it myself?
No need to compile it yourself.
Part of the 0.9.38 work is already in the GitHub source, and I expect to finish and build the release later today. Once it is published, you should be able to just download the macOS package from the Releases page and test it directly.
1 Like
Hi everyone,
Quick follow-up: FerrumPix 0.9.38 is out now, with another round of workflow, RAW, AI and platform improvements.
Editing & Masks
- Crop is now non-destructive within the current editing session for JPEG and PNG too. While you are editing the image, you can reopen the crop and expand the frame again instead of being locked into the previous crop.
- Crop, rotation and straightening now behave more consistently as one transform workflow.
- Large masks are much faster to reopen, paint and use for local corrections.
- Converting a selection into a mask now runs in the background with progress feedback.
RAW & Lens Support
- Updated LibRaw on Windows and Flatpak adds support for around 70 more camera models.
- Updated lens database now covers roughly 1,550 lenses and 1,050 camera bodies.
- RAW demosaicing is now selectable: AHD, DCB or PPG, depending on whether you prefer balance, detail or speed.
- RAW thumbnail quality has also been corrected.
AI & Metadata
- Local AI keywording with RAM++ can now analyse images and add searchable keywords directly to the catalogue.
- AI tagging also works with Immich and Nextcloud images.
- You can control confidence and maximum keyword count, and re-run analysis only on selected folders instead of the whole catalogue.
- Nextcloud can now export metadata to XMP sidecars, including ratings, colour labels, manual keywords and AI keywords.
- Large keyword, people and places lists are now virtualised, which helps a lot with bigger libraries.
Gallery & Workflow
- Rating, favourite, file type and colour-label filters now stay active while moving between folders, instead of resetting every time.
- Folders can now be opened directly from the command line.
- Several catalogue and metadata workflows have been tightened up for larger collections.
macOS & Displays
- macOS now properly finds LibRaw and libheif installed through Homebrew, including on Apple Silicon.
- There is a new experimental Display P3 / wide-gamut option that tells macOS FerrumPix renders in sRGB, so the system can perform display conversion correctly.
- On Linux, UI scaling can now be configured separately for each display.
Thanks again for all the testing and detailed reports, a lot of these changes came directly from feedback over the last few days.
The latest builds are available on GitHub.
2 Likes
v0.9.38 did not fix the wide gamut issue on macOS.
Actually, it had fooled me at first. I opened the same color checker image as last time, took a screen shot, and compared color values. And they matched! But then I noticed the screen shot was in DP3, and the values were supposed to be in sRGB.
And indeed, if I opened Preview side-by side, they show different color values:
This is the DP3 screenshot, converted to sRGB. As you can see, Preview (on the left) shows the correct color values, while FerrumPix (on the right) is still over-saturated. (At least my initial confusion proves that it indeed âassignsâ DP3 to the sRGB image âcorrectlyâ).
A few more notes:
- FerrumPix always start its file browser from âPersonal Folderâ and âRootâ, but all my photos are in the Pictures directory. I can use the Favorites tab to have custom starting points, such as my Pictures directory. But sadly, this wonât show sub-directories. So if I want to see my Pictures directory tree, I canât use Favorites. Would it be possible to see a tree in Favorites, or add additional starting points in the file browser?
- The menu bar on MacOS does not show any menu entries. Thatâs mostly fine, as the application does not have a menu, but it is a bit unusual at least. E.g. Darktable also doesnât have a menu, but at least populates View (Lighttable, DarkroomâŠ), Window (Full Screen mode, Gallery, FillâŠ), and Help. This is useful as these menu entries also show the associated keyboard shortcuts.
- The menu bar on macOS shows the application name as âAvalonia Applicationâ, and if you click âabout Avalonia Applicationâ, it opens the following window:
