The GNOME Foundation is supporting contributors with its fellowship program. You can help expand the fellowship program with a donation.

September was the release month for GNOME 51. That doesn’t only mean a lot of releases but also the starting point for adding new features! My focus for this week was on adding CMYK support to glycin.

CMYK Support for Glycin

The CMYK color model is mainly used for printing, where CMYK (usually) represents cyan, magenta, yellow, and black ink. Working with CMYK is the standard in professional print. But why would glycin need support for it?

The first reason is proper handling of ICC profiles. Assume a JPEG or TIFF stores an image in CMYK. Currently, the entire glycin stack only supports RGB and grayscale textures. Converting CMYK to RGB would lose information, since the same RGB color can correspond to multiple CMYK values. Take, for example, CMY = 100%, which does represent a 100% black. This can also be represented by K = 100%. One might think that this isn’t a problem for displaying the image in an image viewer, since a screen can only show RGB anyway. But there is a catch: ICC profiles. ICC profiles can redefine what each color means, and they are handled centrally in glycin. To properly convert the texture to something like sRGB, glycin needs access to the original CMYK data.

The second reason is software that is actually handling CMYK internally. That’s what Inkscape does. Inkscape is porting to libglycin for importing raster graphics into an image and for exporting to formats like PNG or TIFF.

Properly supporting CMYK needed a bit more work than I expected. But the implementation is now pretty close to getting merged. Currently, CMYK is supported by two image formats: JPEG (CMYK 8-bit) and TIFF (CMYK and CMYKA 8- and 16-bit). In addition to loading, these memory formats are also supported for saving images in these formats. Only writing CMYKA 16-bit is not yet supported for TIFF. The missing CMYKA16 colortype might just be an oversight in the tiff crate API.

For existing users of glycin and libglycin, nothing will change. The default mode is that all CMYK images get converted to sRGB. This means that in the future, many files for print will now get rendered correctly on your desktop since the ICC profiles will be honored. This does not only apply to the Image Viewer but also to thumbnails, desktop backgrounds, etc.

Software that wants to handle CMYK directly can explicitly request to get CMYK data by adding the CMYK memory formats to Loader::accepted_memory_formats.

Other Work

The final comment period for the GNOME RFC process has begun. It has now been pushed back until October 14th. Ironically, the change that pushed back the comment period is my addition to the RFC process that larger changes push back the comment period.

Luckily, this month didn’t come with quite a mystery bug like last month. But there were a few surprising ones.

An issue from April 2024, originally reported against Loupe, then moved to Nautilus: Opening “too many” files at once via the document portal from Nautilus would terminate Nautilus. This was annoying me because I wanted to open a bunch of files in Amberol. The limit is very low on Debian with 16 files. Fedora’s limit is 253 files. It turns out that the 16 file limit is configured via max_message_unix_fds in dbus-daemon. Fedora uses dbus-broker instead, which hits the kernel’s SCM_MAX_FD. The mystery is solved, the issue is not. Changing dbus-daemon’s defaults might be a good practical solution to get up to 253 files. Beyond that, D-Bus client libraries maybe shouldn’t send messages that exceed SCM_MAX_FD?

Another interesting one was glycin failing on older kernel versions. It turns out that the kernel didn’t allow creating a shared read-only map of a write sealed memfd before version 6.7. Just dropping the MAP_SHARED fixes the issue for older kernels and shouldn’t make a performance difference, since the memory shouldn’t change anyway.

That’s all for this month. Talk to you after the spooky month!

Support the GNOME Project

The GNOME Fellowships are funded by our community. If you would like to help the GNOME project to stay sustainable, please consider donating.