Oyranos » KDE http://www.oyranos.org Colour Management System Sun, 03 Dec 2017 18:49:45 +0000 en-US hourly 1 http://wordpress.org/?v=3.5.1 ICC Examin 1.0 on Android http://www.oyranos.org/2017/05/icc-examin-1-0-on-android/ http://www.oyranos.org/2017/05/icc-examin-1-0-on-android/#comments Fri, 19 May 2017 13:26:05 +0000 oy http://www.oyranos.org/?p=2127 Continue reading ]]> ICC Examin allows since version 1.0 ICC Color Profile viewing on the Android mobile platform. ICC Examin shows ICC color profile elements graphically. This way it is much easier to understand the content. Color primaries, white point, curves, tables and color lists are displayed both numerically and as graphics. Matrices, international texts, Metadata are much easier to read.

Features:
* most profile elements from ICC specification version 2 and version 4
* additionally some widely used non standard tag are understood

ICC color profiles are used in photography, print and various operating systems for improving the visual appearance. A ICC profile describes the color response of a color device. Read more about ISO 15076-1:2010 Standard / Specification ICC.1:2010-12 (Profile version 4.3.0.0), color profiles and ICC color management under www.color.org .

The ICC Examin App is completely rewritten in Qt/QML. QML is a declarative language, making it easy to define GUI elements and write layouts with fewer code. In recent years the Qt project extended support from desktop platforms to mobiles like Nokias Meego, Sailfish OS, iOS, Android, embedded devices and more. ICC Examin is available as a paid app in the Google Play Store. Sources are currently closed in order to financially support further development. This ICC Examin version continues to use Oyranos CMS. New is the dependency to RefIccMAX for parsing ICC Profile binaries. In the process both the RefIccMAX library and the Oyranos Color Management System obtained changes and fixes in git for cross compilation with Android libraries. Those changes will be in the next respective releases.

The FLTK Toolkit, as used in previous versions, was not ported to the Android or other mobile platforms. Thus a complete rewrite was unavoidable. The old FLTK based version is still maintained by the same author.

]]>
http://www.oyranos.org/2017/05/icc-examin-1-0-on-android/feed/ 0
Install openSUSE Tumbleweed + KDE on MacBook 2015 http://www.oyranos.org/2017/01/install-opensuse-tumbleweed-kde-on-macbook-2015/ http://www.oyranos.org/2017/01/install-opensuse-tumbleweed-kde-on-macbook-2015/#comments Fri, 27 Jan 2017 15:09:59 +0000 oy http://www.oyranos.org/?p=2093 Continue reading ]]> It is pretty easy to install openSUSE Linux on a MacBook as operating system. However there are some pitfalls, which can cause trouble. The article gives some hints about a dual boot setup with OS X 10.10 and at time of writing current openSUSE Tumbleweed 20170104 (oS TW) on a MacBookPro from early 2015. A recent Linux kernel, like in TW, is advisable as it provides better hardware support.

The LiveCD can be downloaded from www.opensuse.org and written with ImageWriter GUI to a USB stick ~1GB. I’ve choose the Live KDE one and it run well on a first test. During boot after the first sound and display light switches on hold Option/alt key and wait for the disk selection icon. Put the USB key with Linux in a USB port and wait until the removable media icon appears and select it for boot. For me all went fine. The internal display, sound, touchpad and keyboard where detected and worked well. After that test. It was a good time to backup all data from the internal flash drive. I wrote a compressed disk image to a stick using the unix dd command. With that image and the live media I was able to recover, in case anything went wrong. It is not easy to satisfy OS X for it’s journaled HFS and the introduced logical volume layout, which comes with a separate repair partition directly after the main OS partition. That combination is pretty fragile, but should not be touched. The rescue partition can be booted with the command key + r pressed. External tools failed for me. So I booted into rescue mode and took the OS X diskutil or it’s Disk Utility GUI counter part. The tool allows to split the disk into several partitions. The EFI and the rescue ones are hidden in the GUI. The newly created additional partitions can be formatted to exfat and later be modified for the Linux installation. One additional HFS partition was created for sharing data between OS X and Linux with the comfortable Unix attributes. The well know exfat used by many bigger USB sticks, is a possible option as well, but needs the exfat-kmp kernel module installed, which is not by default installed due to Microsofts patent license policy for the file system. In order to write to HFS from Linux, any HFS partition must have switched off the journal feature. This can be done inside the OS X Disk Utility GUI, by selecting the data partition and holding the alt key and searching in the menu for the disable journaling entry. After rebooting into the Live media, I clicked on the Install icon on the desktop background and started openSUSE’s Yast tool. Depending on the available space, it might be a good idea to disable the btrfs filesystem snapshot feature, as it can eat up lots of disk space during each update. An other pitfall is the boot stage. Select there secure GrubEFI mode, as Grub needs special handling for the required EFI boot process. That’s it. Finish install and you should be able to reboot into Linux with the alt key.

My MacBook has unfortunedly a defect. It’s Boot Manager is very slow. Erasing and reinstalling OS X did not fix that issue. To circumvent it, I need to reset NVRAM by pressing alt+cmd+r+p at boot start for around 14 second, until the display gets dark, hold alt on the soon comming next boot sound, select the EFI TW disk in Apple Boot Manager and can then fluently go through the boot process. Without that extra step, the keyboard and mouse might not respond in Linux at all, except the power button. Hot reboot from Linux works fine. OS X does a cold reboot and needs the extra sequence.

KDE’s Plasma needs some configuration to run properly on a high resolution display. Otherwise additional monitors can be connected and easily configured with the kscreen SystemSettings module. Hibernate works fine. Currently the notebooks SD slot is ignored and the facetime camera has no ready oS packages. Battery run time can be extended by spartan power consumption (less brightness, less USB devices and pulseaudio -k, check with powertop), but is not too far from OS X anyway.

]]>
http://www.oyranos.org/2017/01/install-opensuse-tumbleweed-kde-on-macbook-2015/feed/ 4
Watching org.libelektra with Qt http://www.oyranos.org/2016/11/watching-org-libelektra-with-qt/ http://www.oyranos.org/2016/11/watching-org-libelektra-with-qt/#comments Thu, 24 Nov 2016 20:05:19 +0000 oy http://www.oyranos.org/?p=2079 Continue reading ]]> libelektra is a configuration library and tools set. It provides very many capabilities. Here I’d like to show how to observe data model changes from key/value manipulations outside of the actual application inside a user desktop. libelektra broadcasts changes as D-Bus messages. The Oyranos projects will use this method to sync the settings views of GUI’s, like qcmsevents, Synnefo and KDE’s KolorManager with libOyranos and it’s CLI tools in the next release.

Here a small example for connecting the org.libelektra interface over the QDBusConnection class with a class callback function:

Declare a callback function in your Qt class header:

public slots:
 void configChanged( QString msg );

Add the QtDBus API in your sources:

#include <QtDBus/QtDBus>

Wire the org.libelektra intereface to your callback in e.g. your Qt classes constructor:

if( QDBusConnection::sessionBus().connect( QString(), "/org/libelektra/configuration", "org.libelektra", QString(),
 this, SLOT( configChanged( QString ) )) )
 fprintf(stderr, "=================== Done connect\n" );

In your callback arrive the org.libelektra signals:

void Synnefo::configChanged( QString msg )
{
 fprintf( stdout, "config changed: %s\n", msg.toLocal8Bit().data() );
};

As the number of messages are not always known, it is useful to take the first message as a ping and update with a small timeout. Here a more practical code elaboration example:

// init a gate keeper in the class constructor:
acceptDBusUpdate = true;

void Synnefo::configChanged( QString msg )
{
  // allow the first message to ping
  if(acceptDBusUpdate == false) return;
  // block more messages
  acceptDBusUpdate = false;

  // update the view slightly later and avoid trouble
  QTimer::singleShot(250, this, SLOT( update() ));
};

void Synnefo::update()
{
  // clear the Oyranos settings cache (Oyranos CMS specific)
  oyGetPersistentStrings( NULL );

  // the data model reading from libelektra and GUI update
  // code ...

  // open the door for more messages to come
  acceptDBusUpdate = true;
}

The above code works for both Qt4 and Qt5.

]]>
http://www.oyranos.org/2016/11/watching-org-libelektra-with-qt/feed/ 0
High DPI with FLTK http://www.oyranos.org/2016/01/high-dpi-with-fltk/ http://www.oyranos.org/2016/01/high-dpi-with-fltk/#comments Sun, 10 Jan 2016 14:37:18 +0000 oy http://www.oyranos.org/?p=1998 Continue reading ]]> 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.

]]>
http://www.oyranos.org/2016/01/high-dpi-with-fltk/feed/ 0
Web Open Font Format (WOFF) for Web Documents http://www.oyranos.org/2015/07/web-open-font-format-woff-for-web-documents/ http://www.oyranos.org/2015/07/web-open-font-format-woff-for-web-documents/#comments Wed, 01 Jul 2015 14:55:25 +0000 oy http://www.oyranos.org/?p=1957 Continue reading ]]> @font-face { font-family: 'Aladin'; src: url("http://www.oyranos.org/fonts/Aladin-Regular.woff") format("woff"); } .link { font-family: 'Aladin', cursive; font-size: 2em; }

The Web Open Font Format (short WOFF; here using Aladin font) is several years old. Still it took some time to get to a point, where WOFF is almost painless to use on the linux desktop. WOFF is based on OpenType style fonts and is in some way similar to the more known True Type Font (.ttf). TTF fonts are widely known and used on the Windows platform. Those feature rich kind of fonts are used for high quality font displaying for the system and local office-and design documents. WOFF aims at closing the gap towards making those features available on the web. With these fonts it becomes possible to show nice looking fonts on paper and web presentations in almost the same way. In order to make WOFF a success, several open source projects joined forces, among them Pango and Qt, and contributed to harfbuzz, a OpenType text shaping engine. Firefox and other web engines can handle WOFF inside SVG web graphics and HTML web documents using harfbuzz. Inkscape uses at least since version 0.91.1 harfbuzz too for text inside SVG web graphics. As Inkscape is able to produce PDF’s, designing for both the web and print world at the same time becomes easier on Linux.

Where to find and get WOFF fonts?
Open Font Library and Google host huge font collections . And there are more out on the web.

How to install WOFF?
For using inside inkscape one needs to install the fonts locally. Just copy the fonts to your personal ~/.fonts/ path and run

fc-cache -f -v

After that procedure the fonts are visible inside a newly started Inkscape.

How to deploy SVG and WOFF on the Web?
Thankfully WOFF in SVG documents is similar to HTML documents. However simply uploading a Inkscape SVG to the web as is will not be enough to show WOFF fonts. While viewing the document locally is fine, Firefox and friends need to find those fonts independent of the localy installed fonts. Right now you need to manually edit your Inkscape SVG to point to the online location of your fonts . For that open the SVG file in a text editor and place a CSS font-face reference right after the <svg> element like:

</svg>
<style type=”text/css”>
@font-face {
font-family: “Aladin”;
src: url(“fonts/Aladin-Regular.woff”) format(“woff”);
}
</style>

How to print a Inkscape SVG document containing WOFF?
Just convert to PDF from Inkscape’s file menue. Inkscape takes care for embedding the needed fonts and creates a portable PDF.

In case your prefered software is not yet WOFF ready, try the woff2otf python script for converting to the old TTF format.

Hope this small post gets some of you on the font fun path.

]]>
http://www.oyranos.org/2015/07/web-open-font-format-woff-for-web-documents/feed/ 0
Graphical profiling under Linux http://www.oyranos.org/2015/02/graphical-profiling-under-linux/ http://www.oyranos.org/2015/02/graphical-profiling-under-linux/#comments Mon, 09 Feb 2015 20:24:35 +0000 oy http://www.oyranos.org/?p=1882 Continue reading ]]> The Oyranos library became quite slower during the last development cycle for 0.9.6 . That is pretty normal, as new features were added and more ideas waited for implementation letting not much room for all details as wanted. The last two weeks, I took a break and mainly searched for bottlenecks inside the code base and wanted to bring performance back to satisfactory levels. One good starting point for optimisations in Oyranos are the speed tests inside the test suite. But that gives only help on starting a few points. What I wished to be easy, is seeing where code paths spend lots of time and perhaps, which line inside the source file takes much computation time.

I knew from old days the oprofile suite. So I installed it on my openSUSE machine, but had not much success to get callgraphs working. The web search for “Linux profiling” brought me to a article on pixel beat and to perf. I found the article very informative and do not want to duplicate it here. The perf tools are impressive. The sample recording needs to run as root. On the other hand the obtained sample information is quite useful. Most tools of perf are text based. So getting to the hot spots is not straight forward for my taste. However the pixel beat site names a few graphical data representations, and has a screenshot of kcachegrind. The last link under misc guides to flame graphs. The flame graphs are amazing representations of what happens inside Oyranos performance wise. They show in a very intuitive way, which code paths take most time. The graphs are zoom able SVG.

Here an example with expensive hash computation and without in oyranos-profiles:

Computation time has much reduced. An other bottleneck was expensive DB access. I talked with Markus about that already some time ago but forgot to implement. The according flame graph reminded me about that open issue. After some optimisation the DB bottleneck is much reduced.

The command to create the data is:

root$ perf record -g my-command

user& perf-flame-graph.sh my-command-graph-title

… with perf-flame-graph.sh somewhere in your path:

#!/bin/sh
path=/path/to/FlameGraph
output=”$1″
if [ "$output" = "" ]; then
output=”perf”
fi

 

perf script | $path/stackcollapse-perf.pl > $TMPDIR/$USER-out.perf-folded
$path/flamegraph.pl $TMPDIR/$USER-out.perf-folded > $TMPDIR/$USER-$output.svg
firefox $TMPDIR/$USER-$output.svg

One needs FlameGraph, a set of perl script, installed and perf. The above script is just a typing abbreviation.

]]>
http://www.oyranos.org/2015/02/graphical-profiling-under-linux/feed/ 2
Unbound RGB with littleCMS slow http://www.oyranos.org/2014/11/unbound-rgb-with-littlecms-slow/ http://www.oyranos.org/2014/11/unbound-rgb-with-littlecms-slow/#comments Thu, 20 Nov 2014 17:25:41 +0000 oy http://www.oyranos.org/?p=1877 Continue reading ]]> The last days I played with lcms‘ unbound mode. In unbound mode the CMM can convert colours with negative numbers. That allows to use for instance the LMS colour space, a very basic colour space to the human visual system. As well unbound RGB, linear gamma with sRGB primaries, circulated long time as the new one covers all colour space, a kind of replacement of ICC or WCS style colour management. There are some reservations about that statement, as linear RGB is most often understood as “no additional info needed”, which is not easy to build a flexible CMS upon. During the last days I hacked lcms to write the mpet tag in its device link profiles in order to work inside the Oyranos CMS. The multi processing elements tag type (mpet) contains the internal state of lcms’ transform as a rendering pipeline. This pipeline is able to do unbound colour transforms, if no table based elements are included. The tested device link contained single gamma values and matrixes in its D2B0 mpet tag. The Oyranos image-display application renderd my LMS test pictures correctly, in opposite to the 16-bit integer version. However the speed was decreased by a factor of ~3 with lcms compared to the usual integer math transforms. The most time consuming part might be the pow() call in the equation. It is possible that GPU conversions are much faster, only I am not aware of a implementation of mpet transforms on the GPU.

]]>
http://www.oyranos.org/2014/11/unbound-rgb-with-littlecms-slow/feed/ 0
Image Editing with 30-bit Monitors http://www.oyranos.org/2014/05/image-editing-with-30-bit-monitors/ http://www.oyranos.org/2014/05/image-editing-with-30-bit-monitors/#comments Mon, 19 May 2014 05:05:29 +0000 oy http://www.oyranos.org/?p=1777 Continue reading ]]> Payable hardware for professionals is capable of 30-bit throughput since quite some years. And costs continue to go down. This means even budget setups are possible with this kind of gear. So lets follow the question why, who and how monitors capable of displaying 30-bit alias 10-bit per red, green and blue channel can be used. This blog article will first touch some basics, followed by technical aspects below.

Why is it useful to display graphics on a 30-bit monitor setup?
It is essential for graphical editing, to see what effect a editing step has. It is pretty common that low resolution monitors impose a barrier to reliably predict the intended output. This is true for geometrical resolution like for colour resolution and for gamut. The rule of thumb is, the graphics editor needs the most information available to do here/his job and spot artefacts and issues early in the process. This principle is deployed for print, web, film and video editing to reduce costs. You know, redoing something costs time and is part of the jobs calculation. More image information means as well more certainty to reach a graphical result. The typical artefact caused by low colour resolution is reduced tonal range. Colour conversions can reduce the tonal range further. So a sRGB image will look different on a 8-bit per channel monitor with a native gamma close to 2.2 compared to a pipeline with 10-bit per channel. The 8-bit output imposes a bottleneck resulting in loosing some tonal steps known as banding, which must not necessarily be present in the observed sRGB image. One very often read argument against higher bit depth is, that editing hardware shall be as close as possible to customers ones. But that is a illusion. The wide diversity of media and devices makes this nearly impossible. But simulation of end customer hardware is of course an issue and many graphics software has implemented simulation capabilities to address that concern.

Who is most interested in 30-bit colour editing on Linux?
Graphics professional and ambitious users closely observe Linux since many years and deploy it. Many block busters are produced and rendered on Linux machines. Web graphics is well supported since years and camera raw programs implemented a impressive level of features in the last years. So Linux is a potential content creation platform beside content consumption. The typical work flow for content creating people is to generate and edit their art work in high geometrical and colour resolution and down convert to lower resolutions as fits for the job, be that web, print, catalog previews and more flexible high quality delivery depending on actual contract. For instance many photographers archive their shootings in the cameras native format to preserve all available information for later editing or improved rendering. This is a important investment in the future for non short lived work, where old files can shine in new light. Motion picture productions are often rendered and color graded in floating point space by using the OpenEXR intermediate file format and output to 12 bits per component for playback in a cinema. Video production uses in parts raw workflows for advertisements. Medical-, scientific- and archival imaging are potentially interested too and require in parts 30-bit setups like in the DICOM standard. The benefit of 10-bit per channel versus 8-bit does not matter to everyone. Most consumers will not spot any difference while watching web video. But in more demanding areas it is a small but helpful improvement.

How to deploy 30-bit displays on Linux?
That feature was implemented by several companies starting on low level software components like X11, Cairo and pixman. However desktops where pretty slow to adapt software to the new needs and fix bugs. That was in part of the initially higher costs for the hardware. Only few developers in the open source community had early access to suitable gear. I do not write here about suitable graphic cards and monitor combinations. You should consult the web for this. Search for 30-bit monitor. Many early adopters observed psychedelic colours, not working graphics areas and more. Here the state on the well known KDE X11 desktop in release 4.11 on a openSUSE-13.1 . The login screen colours are broken. The splash screen after login looks correct and after some period the desktop becomes visible with again broken colours. To manually fix most of that, one have to tell that Qt shall use native colours. Create following text into a file called ~/.kde4/env/qtnative.sh .

$ kwrite ~/.kde4/env/qtnative.sh

#!/bin/sh
export QT_GRAPHICSSYSTEM=native

With the above variable the desktop should look reasonably in KWin, which is really great. Automating that in Qt would be appreciated.

However 30-bit monitors typical aim at high quality setups. Beside colour resolution they often enough offer a wider gamut than usual monitors. This results in partially heavily saturated colours, which burns in sensible eyes. Those people who do colour grading or photo editing are mostly affected, otherwise they can not easily play this work. So desktop colour correction is an other important feature to enable here. KWin supports ICC based colour correction through KolorManager, which would be useful for the colour saturation. But KWin disables all effects for 30-bit OpenGL visuals. The alternative Compiz-0.8 series has the CompIcc colour server plug-in, which provides the same ICC colour correction feature. To make use of it, one needs to install following packages: compizconfig-settings-manager, CompIcc-0.8.9. Unfortunedly the KDE decorator is no longer available. So use the Emerald decorator from X11:Compiz with the 30-bit-shadow.patch in order to avoid artefacts in the shadow code. Compiz can be used as a default window manager application. Use the system settings to switch to Compiz. Use ccsm to switch on Color Management if not done automatically. And voila the 30-bit desktop should be ready to explore.

What works and what not?
The Plasma desktop is fine including all menus. Dolphin, KWrite, and other applications work. Thunderbird shows some artefacts due to not properly supporting the R10G10B10A2 pixel format. The same is true for Firefox, which lets in parts shine through content behind the Firefox window. Gwenview and ShowFoto work fine within their 8-bit drawing. Only the preview is broken in ShowFoto. Krita supports with the OpenGL backend even native 10-bit per colour component. Menus in Sketch are black. Krita shows minimal artefacts through twice colour converting from image to sRGB by Krita and from sRGB to the monitor colour space by CompIcc. But this effect is much lesser visible than the improvements through its 30-bit support. Applications which try to code 24-bit colour themselves are broken like Konqueror. Gtk and hence Gnome applications with graphical areas do not work. They show black areas. VLC works fine. So daily work should be fine in with 30-bit in the KDE application family depending what you do, with some minor glitches. Valuable Gtk applications as is like Inkscape and most Gtk applications are unusable in a 30-bit setup, with Gimps drawing area being a exception. Thunderbird/Firefox are guessedly affected by the same Gtk bug for which a patch was created some time ago. A patched libgtk-2 is available for testing on openSUSE, which appears to have fixed the problem almost for me.

Beside the need to exchange a windowmanager, to patch a few components and do some manual settings, Linux appears almost there in support of 30-bit setups. Polishing of that feature needs testing of patches and finally acceptance for distribution. Your feedback about bugs, tests and patches can make a difference to developers.

]]>
http://www.oyranos.org/2014/05/image-editing-with-30-bit-monitors/feed/ 15
Firefox-19.0 Colour Management http://www.oyranos.org/2013/03/firefox-19-0-colour-management/ http://www.oyranos.org/2013/03/firefox-19-0-colour-management/#comments Sat, 30 Mar 2013 19:42:04 +0000 oy http://www.oyranos.org/?p=1688 Continue reading ]]>

Firefox detects since version 17.0 the Linux system profile, which is a great improvement for the operating system. While colour conversions on all platforms still default to on for ICC tagged content, they can be enabled for all other colours. Untagged colours will then default to sRGB instead of omitting monitor compensation for them. To do so go to the famous about:config URL and change gfx.color_management.mode from “2″ to “1″. Then use the installed CMS, e.g. on  KDE KolorManager, to set a system monitor profile, and it will be detected after restarting Firefox.

For Android there is no CMS available. That means the ICC monitor profile must be set manually or sRGB will be assumed instead. The settings name in about:config is gfx.color_management.display_profile. Enter into this string the file name with full path, if you are on Android. That procedure is somewhat inconvenient compared to desktops. However the OpenICC group has published some specifications for implementation. This might be even possible for students inside the rewarding Google Summer of Code 2013 program.

For comparison, the Chrome web browser does support colour management on some desktop versions but unfortunately not on Android.

The below false colour test image should look correctly with ICC profile enabled browsers. Look at the colour gradients and then at the colour names and compare.

False colour test imageEnjoy cross platform colour management.

]]>
http://www.oyranos.org/2013/03/firefox-19-0-colour-management/feed/ 0
LibreGraphicsMeeting 2013 coming soon http://www.oyranos.org/2013/01/lgm2013-coming-soon/ http://www.oyranos.org/2013/01/lgm2013-coming-soon/#comments Thu, 24 Jan 2013 12:53:07 +0000 oyranos http://www.oyranos.org/?p=1595 Continue reading ]]> Once a year all or most of the applications around graphics from the free software world come together and work on new ideas and features for there software. The event where they come together is called LibreGraphicsMeeting. Oyranos participated always the last years in that meeting and got a lot of feedback and ideas from it. This year the LibreGraphicsMeeting will take place in Madrid/Spain and there is still time to submit interesting presentations around free software and graphics. As always the LibreGraphicsMeeting tries to collect some money for travel costs of the participating developers.

But there is more, last year we tried to get Gustav Gonzalez to the LGM and it didnt happen. This year Sirko started an campaign very early, as Gustav needs an visa for Spain he has to show flight tickets and accomodation for get it until 15th of February. Now we have nearly the sum for the flights, we looked for flights and we only need arround 200$ for them and another 150$ for accomodation. In case you dont know who Gustav Gonzalez is….

He is the main developer of Tupi, an cool QT 2D animation tool. Which makes it very easy to draw animations. Tupi is an fork of KToon where nobody works on anymore :( But what he has achieved since he forked it, is amazing. Meeting other developer from graphic applications would surly good for him and bring him new ideas for Tupi. SO it would be definitly a benefit to send him to LGM.

]]>
http://www.oyranos.org/2013/01/lgm2013-coming-soon/feed/ 0
Linux Color Management Hackfest Brno 2012 ended http://www.oyranos.org/2012/11/linux-color-management-hackfest-brno-2012-ended/ http://www.oyranos.org/2012/11/linux-color-management-hackfest-brno-2012-ended/#comments Thu, 15 Nov 2012 22:06:51 +0000 oyranos http://www.oyranos.org/?p=1641 Continue reading ]]> Around a dozen people met inside the Red Hat offices in Brno last weekend. The attendees came from various distributions and projects to discuss and work on color management for Linux. Most people arrived at Thursday and we started immediately to brain storm ideas and share information.

I was quite shocked as I heard Dantii could not join us. Fortunately the last messages about him sound very encouraging. It is great that our community could in different ways help him and his family.

The basic concept we worked with during the hackfest, was the opt-out of colour management approach. That was visible in printing and in window manager colour management.

Printing people discussed the PDF/X OutputIntent. The concept was developed to overcome the current short commings in the cupsICCprofile, which is primarily a vendor solution for CUPS print servers and the colord user session hook inside CUPS server. The implementation of the concept was done inside libCmpx, which is basically a wrapper around Ghostscript, which does the majority of the work, and a interface to Oyranos. From the other side John Layt looked into that work and Krita new print colour management tab to understand the implications for the KDE/Qt print dialog. He discussed lively with Till Kamppeter, Richard Hughes, Chris Murphy and me on how to get forward with that. Richard wrote a proof of concept for on screen print simulation in GTK. Chris talked a lot about osX printing and did some testing there. His experience on other platforms than Linux helped us a lot to figure out, which path we want to go and way the make sense. I searched for some PDF’s showing the features we need. They can now be found on ColourWiki. Jaroslav Reznik printed them and Till tested them. Michael Vrhel from the Ghostscript project fixed already after the event all of the bugs, which Till worked on in Brno. We had the idea, that some PDF printers might be able to do the right thing with the OutputIntent themselves. While discussing on how to know about that capability, Till and Richard had a nice idea how to reduce code duplication inside the current set of Linux CUPS filters. In parts the Color Management Hackfest crossed over into a Printing Summit.

Jan Grulich started coding on KolorManager. He implemented a widget to show a 2D graph of a ICC profile inside the information tab. Sirko Kemter was not very happy about the colours inside the graph. So I adjusted them, but after the hackfest.

While working on that, Jan profiled his monitor using Dantii’s colord-kde. Yes, Lukáš Tinkl fixed it, so it can now create ICC profiles. We needed to hand massage the profile to get it into Taxi DB, and then thought, it would be good to download the fresh profile later through Oyranos. That worked fine on the command line. But inside KolorManager a selection that a profile is available for download from Taxi DB would be more appealing. Jan wanted to look into that, and I worked later on a API and code snippet for Oyranos.

By the way, the above screen shot is done using the new colour correction feature for KDE-4.10. You might see the strong colour cast in it. Dan Vrátil worked on undoing that cast inside KSnapshot using the actual monitor profile. The initial coding was fast. But he likes to get that working for multiple outputs too.

Casian Andrei, who did the KWin Color Correction project during this years GSoC, wrote some documentation about that newly added feature. While writing that and clarifying some points, we discussed the opt-out inside KWin and found that it is not yet present. Sig. But Casian had played with the idea already and said that per region opt-out would be trivial inside KWin and started to write on that feature during Sunday. In case that works out, it would be trivial to opt out inside existing applications. But we found as well, that for a perfect results only a blending in the correct colour space is needed during compositing. That can be implemented inside toolkits, which is not trivial, and can then be used together with the per window opt-out. That buys us some valuable time for the toolkits to become ready for full colour management support. Whether the same per region approach is easy enough to implement in Wayland needs to be seen.

Now back to profile distribution. Oyranos obtained a new backup tool for Taxi DB. And we counted already over 200 different ICC profiles in the online data base. Sirko Kemter and Daniel Jahre grabbed the taxi sources, installed MongoDB and worked on mostly basic stuff to add later more features. The online front end to the DB can be used on every platform for download and upload. Daniel and Sirko discussed how to temporarily store a ICC profile from the ColorHug LiveCD. We found that the data base can be used for very different things, e.g. distribution of spectral data sets for camera sensors.

Pippin worked since some time on improving the display of gradients on 8-bit driven monitors. He came up with a dithering approach and tested that using the Taxi DB profiles for the analysis of his implementation. That helped him to make the algorithm more robust even with strongly distorted monitor gamma curves. There is quite some interest inside the graphics designers community for his work to solve banding problems. We talked a bit about gegl and I found babl especially interesting. The small library does, what I call pixel layout conversions. Those are in part colour space conversions and encoding conversions. For better separating encoding, 8-bit versus 16-bit etc., from colour spaces, e.g. linear gamma + Rec709 primaries versus sRGB etc., we need better ICC profile analysis. Especially gamma analysis can be improved inside rendering pipelines. Beside discussing hardware stuff, spectral imaging, video processing and so on, he gave a small and very helpful introduction into colour theory, which was a eye opener for many of the colour management newcomers and thus very welcome.

We had a interesting discussion about financial implications of colour measurement hardware. My impression is the high costs and thus reduced availability for good colour measurement gear nags on the success and acceptance of ICC colour management in consumer and professional markets.

During the hackfest it was really a pleasure to have so many experts in the field in one room and work together in a highly productive atmosphere. Some of them I met the first time. So let me thank our sponsors Google, Red Hat and KDE for their generous support of the hackfest idea.

We all worked quite a lot and found such a event should not stay single. So we agreed already to arrange a one day track and one following day at LGM in Madrid / Spain 2013 under the OpenICC umbrella. I hope we will see then even more projects coming.

]]>
http://www.oyranos.org/2012/11/linux-color-management-hackfest-brno-2012-ended/feed/ 0
Dantii missed at CM Hackfest http://www.oyranos.org/2012/11/dantii-missed-at-cm-hackfest/ http://www.oyranos.org/2012/11/dantii-missed-at-cm-hackfest/#comments Fri, 09 Nov 2012 18:19:07 +0000 oyranos http://www.oyranos.org/?p=1634 Continue reading ]]> Yesterday we heard about the arrest of one of our attendees during his journey to the Linux Color Management Hackfest. We where astonished to hear that the Argentinian police issued a international arrest warrant. As Germany is bound by international agreements to follow that, Dantii was arrested in Munich, where he where on transit. In the process of the german justice act his case will be decided. German courts have a notoriously high workload. So it can easily happen that his case might be handled within the next 6 months, which is quite long. The only chance he has is to obtain documents, which can exonerate his person in this case. Therefor his wife tries to come to Munich and bring the needed documents to Germany. Please consider helping Dantii.
Click here to lend your support to:  URGENT flights to go to the Brazilian Consulate in Munich and make a donation at www.pledgie.com !

]]>
http://www.oyranos.org/2012/11/dantii-missed-at-cm-hackfest/feed/ 0
Oyranos-0.9.0 released http://www.oyranos.org/2012/11/oyranos-0-9-0-released/ http://www.oyranos.org/2012/11/oyranos-0-9-0-released/#comments Fri, 02 Nov 2012 21:57:30 +0000 oyranos http://www.oyranos.org/?p=1624 Continue reading ]]> The first beta of the object oriented C API came out end of last month. It brings a bunch of changes. First, all known Oyranos using projects are updated or have patches available. While the internal changes where heavy weight, most external users had few lines to change. The new APIs where possible through a Google Summer of Code project of Yiannis Belias in  2011. Nearly all C object types and basic functions are generated from django templates, which are interpreted and  processed by the Grantlee engine and a customising plugin.

As we work on WM ICC colour management, we need more facilities to test workflows. In order to support that, the oyranos-icc tool was added and can generate 3D LUTs in various formats. Among them is hald and 3D texture. Te later format is used in CompICC and the new KolorServer of Casian Andrei. The 3D texture is stored as a PPM and can be loaded into the image_display example viewer and drives fast client side colour correction inside OpenGL. The same tool can be used to convert PPM and PNG files through ICC profiles including proofing and effect profiles, much like the C API allows.

The oyranos-profile-graph tool was already described in this blog. New is the generation of ICC profiles out of libRaw/dcraw camera matrices. That is a very nice fallback in case a camera RAW file has no custom profile available. This will not substitute DCP profiles, but is a step forward in integrating camera RAW workflows into ICC driven systems.

default ROMM RGB versus dcraw matrix derived colour space ICC profiles

 

 

]]>
http://www.oyranos.org/2012/11/oyranos-0-9-0-released/feed/ 0
Linux Color Management Hackfest 2012 http://www.oyranos.org/2012/10/linux-color-management-hackfest-2012/ http://www.oyranos.org/2012/10/linux-color-management-hackfest-2012/#comments Mon, 29 Oct 2012 07:40:10 +0000 oyranos http://www.oyranos.org/?p=1611 Continue reading ]]> 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.

]]>
http://www.oyranos.org/2012/10/linux-color-management-hackfest-2012/feed/ 0
Sirko’s Laptop arrived http://www.oyranos.org/2012/09/sirkos-laptop-arrived/ http://www.oyranos.org/2012/09/sirkos-laptop-arrived/#comments Thu, 27 Sep 2012 08:55:33 +0000 oyranos http://www.oyranos.org/?p=1606 Continue reading ]]> In july we started a pledgie to collect money to get a new work horse for Sirko Kemter. He is a artist, author and event organiser with strong involvement in open source . He was far too long in need to work on a reliable machine, which can be taken to conferences and workshops. His laptop arrived on 25th september 2012.

We are happy about the great response of the community and like to thank everybody who donated or raised awareness about the campaign. Much luck and fun with your new mobile workplace, Sirko.

]]>
http://www.oyranos.org/2012/09/sirkos-laptop-arrived/feed/ 0
OpenICC Google Summer of Code 2012 results http://www.oyranos.org/2012/09/openicc-google-summer-of-code-2012-results/ http://www.oyranos.org/2012/09/openicc-google-summer-of-code-2012-results/#comments Thu, 13 Sep 2012 05:53:50 +0000 oyranos http://www.oyranos.org/?p=1580 Continue reading ]]>

Google Summer of Code

Participation of the OpenICC group in the Google Summer of Code 2012 program was this year a great success. All projects reached their respective goals. Here a small summary:

Colour Management for Krita Printing
Joseph Simon worked on adaption and integration of his last years implementation for colour managed printing into Krita/Linux. The workflow is based on ICC profile injection into PDF through the means of a OutputIntent.

KWin Colour Correction
Casian Andrei’s KWin changes for ICC style colour correction in the GPU are reviewed upstream and his new code to the KolorManager code base waits just for approval. The concept follows the X Color Management spec. In contrast to the elder CompICC implementation is the KWin result highly modular and thus very flexible.

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.

]]>
http://www.oyranos.org/2012/09/openicc-google-summer-of-code-2012-results/feed/ 0
A laptop for Sirko http://www.oyranos.org/2012/07/a-laptop-for-sirko/ http://www.oyranos.org/2012/07/a-laptop-for-sirko/#comments Mon, 02 Jul 2012 05:30:52 +0000 oyranos http://www.oyranos.org/?p=1561 Continue reading ]]>

Sirko, alias gnokii, needs a new laptop. His old one is mostly broken and horrible outdated, a OS update appears hard, wireless-network is non existent and can not added though the USB-1 connector. He works so much for the open source graphics community, that it is hard for him to spent time on ordinary money making. But the FLOSS community profits much from his digital art and design work. Many projects, events and distributions obtained flyers, logos, posters, web site designs and so on from Sirko. Or you can visit his vector graphics on openclipart.org, attend one of his graphics workshops on FLOSS events or enjoy his Inkscape tutorials online. Because of all these reasons, we like to see him happy using and presenting Inkscape and all the other graphic tools by helping him getting a actual graphics laptop.

A common device among designers appears to be one of the Lenovo Thinkpad Laptops. They are durable and well useable during long bus and train travels. A L420appears to be a good workhorse for a skilled artist like gnokii. Hence the final goal of this campaign. The next events with him start already in august.For extraordinary contributions you can contact me under: ku.b at gmx dot de

Netbook

Click here to lend your support to: gnokii

]]>
http://www.oyranos.org/2012/07/a-laptop-for-sirko/feed/ 1
LibreGraphicsMeeting Videos http://www.oyranos.org/2012/06/libregraphicsmeeting-videos/ http://www.oyranos.org/2012/06/libregraphicsmeeting-videos/#comments Mon, 18 Jun 2012 05:22:17 +0000 oyranos http://www.oyranos.org/?p=1530 Continue reading ]]> In begin of May there was the 7th LibreGraphicsMeeting in Vienna and Oyranos participated also this year in this meeting of nearly all free/open source graphic software. Oyranos had two talks there and I already blogged the impressions. Now the most of the videos from the talks are online.

The playlist with all talks which was recorded can be found here.

]]>
http://www.oyranos.org/2012/06/libregraphicsmeeting-videos/feed/ 0
ICC profile graphs http://www.oyranos.org/2012/06/icc-profile-graphs/ http://www.oyranos.org/2012/06/icc-profile-graphs/#comments Fri, 15 Jun 2012 13:58:57 +0000 oyranos http://www.oyranos.org/?p=1537 Continue reading ]]> During the recent days I improved the file dialog preview of ICC Examin. As a result I created a new Oyranos tool called oyranos-profile-graph, which can be found in git. It provides a simple icon and can potentially be used in tools like Synnefo or KolorManager‘s info tab.

There exist some graphing tools like ppmcie to generate a nice triangle inside a CIE*xy horse shoe.

CIE*xy graph from ppmcie

But as ICC Examin sticks on CIE*Lab, I think it is more appropriate to use the CIE*a*b projection instead. Both are available by oyranos-profile-graph. The graphical output of the tool is really simple, beside using Cairo for antialiased curves. Below are the 2D graphs for sRGB.icc LStar-RGB.icc ProPhoto-RGB.icc ISOcoated_v2_bas.ICC ISOuncoatedyellowish_bas.ICC profiles. The first graph is CIE*ab and the second shows the same saturation lines in CIE*xy.

 

]]>
http://www.oyranos.org/2012/06/icc-profile-graphs/feed/ 1
Movie LUT’s inside ICC Profiles http://www.oyranos.org/2012/06/movie-luts-inside-icc-profiles/ http://www.oyranos.org/2012/06/movie-luts-inside-icc-profiles/#comments Tue, 05 Jun 2012 20:24:26 +0000 oyranos http://www.oyranos.org/?p=1504 Continue reading ]]> Krita, a painting application with high dynamic range (HDR) support, is in the planning phase for the next release cycle. One hot topic is currently the discussion about what can be done to make movie makers even more happy. A good candidate is the marriage of film industry colour management with Krita’s inbuilt ICC style colour management. But Krita maintainer Boudewijn Rempt expressed surprise about movie style colour management in other apps.

This post tries to compare how both colour management worlds work and how they can better fit for the advantage of each other.

The ICC format standard is for its most popular flavors designed as a characterisation of one colour space conversion in reference to the standard observer colour space or in ICC terms the PCS. That allows a very flexible combining of ICC profiles from many different devices into colour transformations and is one of the basic principles of the ICC standard. The advantage of using existing ICC workflows is, that tools for on the fly monitor colour correction are almost all ICC based and well understood.

So, how does the movie industry currently define colour spaces in their workflows?

In short, film colour spaces are characterised by standards and not by ICC profiles. On a technically level the involved file formats use pretty much the same basics. That is, curves and 3D tables, which are available inside the ICC foraremat as well.

However colour tables of movie makers, called LUT’s, are very closely related to the intended usage during film production. These LUT’s can combine a colour space conversion from a source colour space: typically a linear gamma floating point encoding toward a final display.

A simple colour conversion with just two ICC profiles would not adequately represent how a good movie picture should look like. So adding of scaling curves is needed, to obtain a tonal representation of  brighter than white parts of a scene. That part can include logarithmic scaling or other methods. An S shaped gamma is sometimes used to get a closer to film look of the footage output and possibly more tricks are used to create a pleasing colour output. And last but not least, the simulation of the intended output device, as in a typical cinema, is most often baked into film production LUT’s.

So a LUT contains the original source colour space and many additional ingredients. Movie makers have searched for ways to use their LUTs inside traditional ICC colour managed software: in one approach, they simply placed the LUT inside a ICC profile and could use the LUT’s in more software, typical as a proofing profile. A proofing profile is a normal ICC output profile describing the colour behaviour of a single devices. For film makers that is pretty much the way they use LUT’s anyway: as colour conversions in their workflows.

The approach of LUT baking into ICC output profiles is semantically not a good fit. However, there exist two other not so well known ICC format flavors, which could be far better deployed in order to support film LUT’s style colour conversions.

The one which comes technically closest to a film LUT is the “device link profile class”. A device link profile represents a combination of a complete colour transformation over a arbitrary number of colour spaces and manipulations into one final colour profile. As input and output colour spaces are included, a device link profile is pretty much a fixed thing like a LUT. But that means, it completely misses the flexibility of normal ICC profiles: that is the ability to get combined with different devices in an almost automatic fashion, with little user interaction if at all.

Another ICC profile type candidate is the abstract or effect style” ICC profile. These profiles can be used to simulate a device, do a colour manipulation or a combination of different conversions. The big advantage of the “abstract or effect profile” class is the very common PCS reference for the input and output side. So these profiles can easily be chained between a input colour space and a monitor device profile.

Baking movie LUT’s inside abstract profiles instead of device profiles would work more nicely inside ICC style workflows. Then, applications which support effect profiles can simply select the right effect LUT without touching a source colour space or even the monitor profiles, which would, among most people familiar with ICC style colour management, be considered a hack, and with reason.

The idea of using abstract profiles inside a painting application is not new. It was demonstrated around 2004 inside the CinePaint open source application. The abstract profiles were, for convenience, called “look profiles” inside the UI. CinePaint allowed users to chain “look profiles” and comfortably enable and disable them in order to see their effect.

The “look profiles” where used on the fly, without touching the image colour space. It was also possible to apply “look profiles” irreversibly and persistently to a image. The decision for CinePaint’s “look profile” workflow was directly inspired by movie studio needs.

At the time the underlying lcms library supported only 8 and 16-bit per channel. With the upcoming half floating point support in lcms, the “look profile” workflow starts soon to make sense as well for OpenEXR images. Lcms implemented further support of floating point elements inside ICC profiles to meet higher precision needs of the film industry. It will be interesting to see how this can be utilised.

]]>
http://www.oyranos.org/2012/06/movie-luts-inside-icc-profiles/feed/ 0