After switchig to a notebook with higher resolution monitor, I noticed, that the FLTK based ICC Examin application looked way too small. Having worked in the last months much with pixel independent resolutions in QML, it was a pain to see the non adapted FLTK GUI. I had the impression, that despite of several years of a very appreciated advancement of monitor technology, some parts of graphics stacks did not move and take advantage. So I became curious on how to solve high DPI support the hard way.
First of all a bit of introduction to my environment, which is openSUSE Linux and KDE-5 with KF5 5.5.3. Xorg use many times a hardcoded default of 96 dpi, which is very unfortune or just a bug? Anyway, KDE follows X11. So the desktop on the high resolution monitor looks initially as bad as any application. All windows, icons and text are way too small to be useable. In KDE’s system settings, I had to set Force Font with DPI and doubled its size from 96 to 192. In the kscreen module I had to set scale 2.0 and then increased the KDE task bars width. Out of the box useability is bad with so many inconsistent manual user intervention. In comparision with the as well tested Unity DE, I had to set a single display scaling factor to 2.0 and everything worked fine and instantly, icons, fonts and window sizes. It would be cool if DE’s and Xorg understand screen resolution. In the tested OS X 10.10 even different screen resolutions of multiple monitors are scaled correctly, so moving a window from a high DPI monitor screen to a traditional low resolution external monitor gives reasonable physical GUI rendering. Apples OS X provides that good behaviour initially, without manual user intervention. It would be interessting how GNOME behaves with regards to display scaling.
Back to FLTK. As FLTK appears to define itself as pixel based, DPI detecion or settings have no effect in FLTK. As a app developer I want to improve user experience and modified first ICC Examin to initially render physically reasonably. First I looked at the FL::screen_dpi() function. It is only a helper for detecting DPI values. FL::screen_dpi() has has in FLTK-1.3.3 hardcoded values of 96DPI under Linux. I noticed XRandR provides correct milimeter based screen dimensions. Together with the XRandR provided screen resolution, it is easy to calculate the DPI values. ICC Examin renderd much better with that XRandR based DPI’s instead of FLTK’s 96DPI. But ICC Examin looked slightly too big. The 192DPI set in KDE are lower than the XRandR detected 227 DPI of my notebooks monitor. KDE provides its forced DPI setting to applications by setting Xft.dpi in XResources. That way all Xft based applications should have the same basic font scaling. KDE and Mozilla apps do use Xft. So add parsing of a Xlib XResources solved that for ICC Examin. The remainder of programing was to programatically scale FLTK’s default font size from 14 pixels with: FL_NORMAL_SIZE = scale(14) . Some more widget sizes, the FtGl font sizes for OpenGL, drawing line widths and graphics scaling where needed. After all those changes, ICC Examin takes now advantage of high resolution rendering inside KDE. Testing under Windows and OS X must follow.
The way to program high DPI support into a FLTK application was basically the same as in QML. However Qt’s QML takes off more tasks by providing a relative font unit, much like CSS em sizes. For FLTK, I would like to see some relative based API’s, in addition to the pixel based API’s. That would be helpful to write more elegant code and integrate with FLTK’s GUI layout program fluid. Computer times point more and more toward W3C technology. FLTK would be helpful to follow.
The hackfest in Brno is approaching fast. I wrote earlier this year about the idea. It will happen from 9th until 12th November 2012 inside the Red Hat Czech office. Talks with our local organiser and various sponsors went good so far. People will code in Brno on various topics around color management in Linux.
The main focus looks like to be at applications, desktop and library integration. For the printing system and Taxi DB was good interest too. As the event is organised as a framework for attendees, each one will decide, what is best to do. After a morning meeting, where we can coordinate, we will likely split in smaller groups according to a choosen topic or move around as needed. We hope that works for all attendees. There are specialists present for many Linux color topics for discussion and of course color management newbies can ask them to effectively improve their project.
Simple Toolkit Abstraction
Nitin Chadas SimpleUI project for rendering a subset of XForms was written from
ground up and provides now backends for FLTK, Gtk and Qt. It needs a bit
of polishing to become useable.
Thanks to Google for providing the colour management and graphics community again a great chance to code and learn the open source way.
Sirko brought up the idea to organise a hackfest together with developers of applications for Linux desktops and experts interested in colour management. The idea behind that event was to bring interested developers together, support them in implementing color management in their software and move forward that topic across desktops and distributions.
During the recent LGM we found a chance to involve Richard Hughes and planed together about what we like to do during the hackfest. We spotted three main areas of interest: desktop applications including window managers, web browsers and printing. These topics are already worked on, but in a scattered way.
As example, Gwenview is a really great application for managing pictures. But it has no color management implemented yet. Color management in KWin is worked on during the GSoC this year, but in the opposite color management in the compositing manager mutter on the GNOME side is far away as can be read here. Not many web browsers support color management and if they who do, it is often incomplete. The SVG v2 standard will for example introduce additional color management features compared to SVG v1. So it is now the right time to get these implemented in order to be well prepared. For the KDE printing stack there is also a GSoC project this year, but also the Linux Foundation has a working group for this topic.
So, by meeting in person in one place, we want to get something done and build a good understanding of the role of each participating group for a working end to end colour management.
The hackfest will very likely happen in Brno in the Czech Republic at the Red Hat offices. A good time appears later this year 16th till 19th November. Now we like to collect more ideas, speak to people and sort financial issues.
OpenICC obtained three project slots for the Google Summer of Code 2012
stipends. That means three students can work again this year full time over
three summer months on colour management projects. Thanks to Google for
organising and sponsoring the program.
Casian Andrej will work on ICC KWin colour correction using the X Color
Management spec. That way KWin gets a clear path toward consistent colour
output on the desktop.
Nitin Chada will work on different toolkit dependent renderers for a
XForms subset inside the Simple Toolkit Abstraction project. That standalone project shall enable modules to present
options inside dialogs or embedded in host applications.
Lets have a successful coding summer and deserve the trust Google putted in
the OpenICC organisation and with that in the participating students.
A new version of the compiz plugin for ICC colour correction of monitors is released. This release is a feature release.
new support per region ICC profiles
new switch to X Color Management specification
require libXcm-0.5.0 and Oyranos-0.4.0
Changes from 0.8.4:
fix alpha blending
speed up load time (cache the transformed pixels in memory)
The project brings you instant desktop colour correction on GPU through the compiz window manager (0.7.x/0.8.x). It supports multi monitors and live connecting. The implicite colour conversion appears on the fly. To opt out of colour correction for specialised graphics applications the X Color Management spec 0.4 is supported. Devices can be configured through the Oyranos Colour Management System.
ICC Examin Version 0.51 is a feature release. The package newly explores into window and OpenGL colour correction and contains bug fixes.
new on the fly large gamut intermediate ICC profile
new let a colour server colour correct OpenGL
new Oyranos colour corrects report window on CPU
fix regression in file observation
require Oyranos 0.4.0
ICC Examin is a small utility (unix name: iccexamin) for the purpose of watching the internals of ICC v2 and v4 profiles, measurement data (CGATS), colour samples (named colour profiles), gamut visualisations (vrml) and video card gamma tables (Xorg/XFree86/osX).
The new version of the colour management system Oyranos is released. Version 0.4.0 is a feature and bug fix release.
new list Taxi DB profiles for a local monitor
new download and install ICC profiles from Taxi DB
fix HDMI2 XRandR EDID
new widget classes to image_display for per window CM
new add oyranos-monitor-daemon script
switch to libXcm 0.5.0 for X Color Management support
Oyranos is a colour management system allowing to share various settings across applications and services. The provided interfaces are the C library, native graphical front ends and partitial access through command line tools. The library is licensed under newBSD.
Known Applications using Oyranos:
ICC Examin, the KDE Kolor Manager and Synnefo configuration dialogs, the CompIcc colour server and more.
This is a major new release of libXcm, the X11 Color Management library. The name space of the core protocol changed with the new spec.
switch from net-color to X Color Management specification 0.4
support per region ICC profile
add API to parse capabilities from _ICC_COLOR_DESKTOP atom
add XcmVersion.h file
build under osX and Win32 without X11 and Linux specific parts
The library communicates X colour regions between server and clients, which is described in the included X Color Management spec. EDID data can be fetched through i2c communication. EDID data can be parsed for identification and access to colorimetric
calibration data. libXcm helps in observing known X11 colour management events.
Known applications using libXcm:
The library is used by CompIcc a compiz plugin for full screen colour correction in hardware. libXcm allows the plugin to support multi monitor and multiple regions per window. The Oyranos Colour Management System uses the EDID parser. qcmsevents applet observes and displays colour management events in a nice GUI. Xcm contains three command line tools for EDID fetching, EDID parsing and event observing.
The last blog posts about KDE and colour management might have been irritating about what actual happens on colour managed desktops. Here come some clarifications and thoughts from the Oyranos CMS maintainer. The project name starts with Oy (Oyranos like sky), hence my nick oy on IRC
Colour Management Systems (CMS) are a precondition to do colour correction of input and output devices. But this is not sufficient for having a colour corrected desktop. The claim was made, that Gnome is the first colour managed desktop on Linux. But Gnomes window manger mutter has no means to use ICC profiles. The same is true for all other window managers with an exception of old Compiz. A CMS selects only the needed ICC profile and does the configuration in that field. But the background, applications like the dock and most others are not colour corrected by standard ICC profiles mechanisms in Linux. The only thing users can do since many years on Linux is to do monitor calibration setup per single channel. This helps for better grayscale, but not for compensating of colour gamuts. Calibration is only a first step, but not sufficient for ICC colour correction. So Gnome users have today no colour corrected desktop like all other Linux users.
What is needed to get to a End to End colour corrected desktop in KDE? A more general Overview can be found here.
KWin needs ICC support, in order to colour correct the KDE desktop in a reasonable time frame. That will help with the output side in a fast way by using the GPU during compositing while using few resources. If you feel it is time to do something, here is a Google Summer of Code CM project idea for KWin. With my experience from the CompICC project, I would be glad to help any such project.
An other project I would find really helpful is to provide colour correction to KDE’s primary image viewer gwenview. If people could help with a hackfest, that would be cool. We have such thing in mind and some ideas about, maybe you like to join us.
Qt/KDE needs to explore how to do own fast colour correction of a complete window to be prepared for the future. Here are two project ideas.
OpenICC did investigate to get print colour management right. There are currently two approaches who are promising. OpenICC has one project idea to introduce colour managed printing into Krita and one for user profile setup for colour managed print queues with KolorManager. These are two complementing, maintainable and robust paths for getting printing CM right.
Now some clarifications about Oyranos itself, as in the kde-planet where many wrong statements transported intermixed with half true claims.
Core is a toolkit independent library
KDE, Qt and FLTK front ends exist like KolorManager. Other native ones are possible.
The Elektra API and library is used for format independent configuration DB access.
Oyranos is planed to switch to a OpenICC JSON DB format to converge with ArgyllCMS and other interested CMS’es
Oyranos is a cross platform project
A DBus API would be welcome on top of the basic library but not in its core
Oyranos forces no one to use the CPU or prohibit to use the GPU
The CMS provides means to do optional multi monitor colour correction and other conversions.
CompICC uses Oyranos and does colour correction on the GPU
Oyranos developers belief in collaboration
Self containment in Oyranos results from adhering to and work on interoperable standards.
User configurations belong to users in Oyranos, so it needs no special root rights, which exposes security and privacy risks.
Oyranos provides optional policies for grouping single settings. That is a additional feature not a limitation.
Oyranos uses many advanced automatism’s to do it’s work successful
The CMS is designed to work with default settings.
Advanced manual configurations are supported and part of Oyranos’ user centrism.
Oyranos cares about quality and requires a careful selected and peer reviewed profile set that comes with no Fakes and no wrong colorimetry.
Licensing fits most open source and commercial projects with a newBSD style license.
Choice is a good thing for users. As a CMS author I have no problems, that an other CMS comes to KDE too on Linux. Many Linux CM standards I initiated or helped with allow for such interoperability, which is in the spirit of the ICC standard.