Oyranos 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.

* 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, 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
Responsive HTML with CSS and Javscript http://www.oyranos.org/2016/11/responsive-html-with-css-and-javscript/ http://www.oyranos.org/2016/11/responsive-html-with-css-and-javscript/#comments Wed, 16 Nov 2016 07:03:45 +0000 oy http://www.oyranos.org/?p=2072 Continue reading ]]> In this article you can learn how to make a minimalist web page readable on different format readers like larger desktop screens and handhelds. The ingredients are HTML, with CSS and few JavaScript. The goals for my home page are:

  • most of the layout resides in CSS in a stateless way
  • minimal JavaScript
  • on small displays – single column layout
  • on wide format displays – division of text in columns
  • count of columns adapts to browser window width or screen size
  • combine with markdown


h1,h2,h3 {
  font-weight: bold;
  font-style: normal;

@media (min-width: 1000px) {
  .tiles {
    display: flex;
    justify-content: space-between;
    flex-wrap: wrap;
    align-items: flex-start;
    width: 100%;
  .tile {
    flex: 0 1 49%;
  .tile2 {
    flex: 1 280px
  h1,h2,h3 {
    font-weight: normal;
@media (min-width: 1200px) {
  @supports ( display: flex ) {
    .tile {
      flex: 0 1 24%;

The content in class=”tile” is shown as one column up to 4 columns. tile2 has a fixed with and picks its column count by itself. All flex boxes behave like one normal column. With @media (min-width: 1000px) { a bigger screen is assumed. Very likely there is a overlapping width for bigger handhelds, tablets and smaller laptops. But the layout works reasonable and performs well on shrinking the web browser on a desktop or viewing fullscreen and is well readable. Expressing all tile stuff in flex: syntax helps keeping compatibility with non flex supporting layout engines like in e.g. dillo.

For reading on High-DPI monitors on small it is essential to set font size properly. Update: Google and Mozilla recommend a meta “viewport” tag to signal browsers, that they are prepared to handle scaling properly. No JavaScript is needed for that.

<meta name="viewport" content="width=device-width, initial-scale=1.0">

[Outdated: I found no way to do that in CSS so far. JavaScript:]

function make_responsive () {
  if( typeof screen != "undefined" ) {
    var fontSize = "1rem";
    if( screen.width < 400 ) {
      fontSize = "2rem";
    else if( screen.width < 720 ) {
      fontSize = "1.5rem";
    else if( screen.width < 1320 ) {
      fontSize = "1rem";
    if( typeof document.children === "object" ) {
      var obj = document.children[0]; // html node
      obj.style["font-size"] = fontSize;
    } else if( typeof document.body != "undefined" ) {
      document.body.style.fontSize = fontSize;
document.addEventListener( "DOMContentLoaded", make_responsive, false );
window.addEventListener( "orientationchange", make_responsive, false );

[The above JavaScript checks carefully if various browser attributes and scales the font size to compensate for small screens and make it readable.]

The above method works in all tested browsers (FireFox, Chrome, Konqueror, IE) beside dillo and on all platforms (Linux/KDE, Android, WP8.1). The meta tag method works as well better for printing.

Below some markdown to illustrate the approach.


<div class="tiles">
<div class="tile"> My first text goes here. </div>
<div class="tile"> Second text goes here. </div>
<div class="tile"> Third text goes here. </div>
<div class="tile"> Fourth text goes here. </div>

In my previous articles you can read about using CSS3 for Translation and Web Open Font Format (WOFF) for Web Documents.

http://www.oyranos.org/2016/11/responsive-html-with-css-and-javscript/feed/ 0
CSS3 for Translation http://www.oyranos.org/2016/11/css3-for-translation/ http://www.oyranos.org/2016/11/css3-for-translation/#comments Tue, 15 Nov 2016 15:46:44 +0000 oy http://www.oyranos.org/?p=2058 Continue reading ]]> Years ago I used a CMS to bring content to a web page. But with evolving CSS, markdown syntax and comfortable git hosting, publication of smaller sites can be handled without a CMS. My home page is translated. Thus I liked to express page translations in a stateless language. The ingredients are simple. My requirements are:

  • stateless CSS, no javascript
  • integrable with markdown syntax (html tags are ok’ish)
  • default language shall remain visible, when no translation was found
  • hopefully searchable by robots (Those need to understand CSS.)


/* hide translations initially */
.hide {
  display: none
/* show a browser detected translation */
:lang(de) { display: block; }
li:lang(de) { display: list-item; }
a:lang(de) { display: inline; }
em:lang(de) { display: inline; }
span:lang(de) { display: inline; }

/* hide default language, if a translation was found */
:lang(de) ~ [lang=en] {
 display: none;

The CSS uses the display property of the element, which was returned by the :lang() selector. However the selectors for different display: types are somewhat long. Which is not so short as I liked.


<span lang="de" class="hide"> Hallo _Welt_. </span>
<span lang="en"> Hello _World_. </span>

Even so the plain markdown text looks not as straight forward as before. But it is acceptable IMO.

Hiding the default language uses the sibling elements combinator E ~ F and selects a element containing the lang=”en” attribute. Matching elements are hidden (display: none;). This is here the default language string “Hello _World_.” with the lang=”en” attribute. This approach works fine in FireFox(49), Chrome Browser(54), Konqueror(4.18 khtml&WebKit) and WP8.1 with Internet Explorer. Dillo(3.0.5) does not show the translation, only the english text, which is correct as fallback for a non :lang() supporting engine.

On my search I found approaches for content swapping with CSS: :lang()::before { content: xxx; } . But those where not well accessible. Comments and ideas welcome.

http://www.oyranos.org/2016/11/css3-for-translation/feed/ 0
Digital diaphragm for optical lenses http://www.oyranos.org/2016/06/digital-diaphragm-for-optical-lenses/ http://www.oyranos.org/2016/06/digital-diaphragm-for-optical-lenses/#comments Sun, 05 Jun 2016 21:00:36 +0000 oy http://www.oyranos.org/?p=2033 Continue reading ]]> In photography most optical lenses use mechanical diaphragms for aperture control. They are traditionally manufactured from metal blades and works quite good. However metal blades exposes some disadvantages:

  • mechanical parts will sooner or later fail
  • the cheaper forms give strong diffraction spikes
  • manufacturers need more metal blades for a round iris, which is expensive
  • a metal blade with its sharp edges give artefacts, which are visible in out of focus regions.
  • but, contrast is very high by using opaque metal

In order to obtain a better bokeh, some lenses are equipped with apodization filters. Those filters work mostly for fully open arperture and are very specialised and thus relatively expensive.

A digital arperture build as a transparent display with enough spatial resolution can not only improve the shape of the diaphragm. It could feature as a apodisation filter, if it supports enough gray levels. And it can change its form programatically.

Two possible digital diaphragm forms:

  • leverage existing display technology
  • better aperture shape for reduced artefacts
  • apodisation filter on demand for best bokeh or faster light
  • programmable or at least updateable aperture pattern (sharp/gausian/linear/…)
  • no metal blades or other mechanical parts to fail
  • over the years get cheaper than mechanical counterpart
  • reduce number of glas to air surfaces in optical lens design
  • integratable aperture into lens groups
  • display transparency increases quickly and is for OLED at 45% by 2016, which means at the moment just one f-stop
  • mobile demands high display resolutions anyway

The digital arperture can easily be manufactured as a monochrome display and be placed traditionally between two optical lens groups, where today the diaphragm is located. Or it is even possible to optically integrate the aperture into one lens group, without additional glas to air surfaces, as is needed with moving blades. Once the optical quality of the digital filter display is good enough a digital diaphragm can be even cheaper than a high quality mechanical counterpart.

http://www.oyranos.org/2016/06/digital-diaphragm-for-optical-lenses/feed/ 0
http://www.oyranos.org/2016/01/2014/ http://www.oyranos.org/2016/01/2014/#comments Sat, 23 Jan 2016 05:57:13 +0000 oy http://www.oyranos.org/?p=2014 Continue reading ]]> Bit shifting, done by the << and >> operators, allows in C languages to express memory and storage access, which is quite important to read and write exchangeable data. But:

Question: where is the bit when moved shifted left?

Answere: it depends

Long Answere:

// On LSB/intel a left shift makes the bit moving 
// to the opposite, the right. Omg 
// The shift(<<,>>) operators follow the MSB scheme
// with the highest value left. 
// shift math expresses our written order.
// 10 is more than 01
// x left shift by n == x << n == x * pow(2,n)
#include <stdio.h> // printf
#include <stdint.h> // uint16_t

int main(int argc, char **argv)
  uint16_t u16, i, n;
  uint8_t * u8p = (uint8_t*) &u16; // uint16_t as 2 bytes
  // iterate over all bit positions
  for(n = 0; n < 16; ++n)
    // left shift operation
    u16 = 0x01 << n;
    // show the mathematical result
    printf("0x01 << %u:\t%d\n", n, u16);
    // show the bit position
    for(i = 0; i < 16; ++i) printf( "%u", u16 >> i & 0x01);
    // show the bit location in the actual byte
    for(i = 0; i < 2; ++i)
        printf(" byte[%d]", i); 
  return 0;

Result on a LSB/intel machine:

0x01 << 0:      1 
1000000000000000 byte[0] 
0x01 << 1:      2 
0100000000000000 byte[0] 
0x01 << 2:      4 
0010000000000000 byte[0] 
0x01 << 3:      8 
0001000000000000 byte[0]

<< MSB Moves bits to the left, while << LSB is a Lie and moves to the right. For directional shifts I would like to use a separate operator, e.g. <<| and |>>.

http://www.oyranos.org/2016/01/2014/feed/ 1
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("/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:

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

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
Portable Float Map with 16-bit Half http://www.oyranos.org/2015/03/portable-float-map-with-16-bit-half/ http://www.oyranos.org/2015/03/portable-float-map-with-16-bit-half/#comments Sun, 08 Mar 2015 23:05:26 +0000 oy http://www.oyranos.org/?p=1919 Continue reading ]]> Recently we saw some lively discussions about support of Half within the Tiff image format on the OpenEXR mailing list. That made me aware of the according oyHALF code paths inside Oyranos. In order to test easily, Oyranos uses the KISS format PPM. That comes with a three ascii lines header and then the uncompressed pixel data. I wanted to create some RGB images containing 16-bit floating point half channels, but that PFM format variant is not yet defined. So here comes a RFC.

A portable float map (PFM) starts with the first line identifier “Pf” or “PF” and contains 32-bit IEEE floating point data. The 16-bit IEEE/Nvidia/OpenEXR floating point data variant starts with a first line “Ph” or “PH” magic similar to PFM. “Ph” stands for grayscale with one sample. The “PH” identifier is used for RGB with three samples.

That’s it. Oyranos supports the format in git and maybe in the next 0.9.6 release.

http://www.oyranos.org/2015/03/portable-float-map-with-16-bit-half/feed/ 0
Reanimation of MacBook Air http://www.oyranos.org/2015/02/reanimation-of-macbook-air/ http://www.oyranos.org/2015/02/reanimation-of-macbook-air/#comments Tue, 17 Feb 2015 21:37:16 +0000 oy http://www.oyranos.org/?p=1903 Continue reading ]]> For some months our MacBook Air was broken. Finally good time to replace, I thought. On the other side, the old notebook was quite useful even 6 years after purchasing. Coding on the road, web surfing, SVG/PDF presentations and so on worked fine on the Core2Duo device from 2008. The first breaking symptoms started with video errors on a DVI connected WUXGA/HDTV+ sized display. The error looked like non stable frequency handling, with the upper scan lines being visually ok and the lower end wobbling to the right. A black desktop background with a small sized window was sometimes a workaround. This notebook type uses a Nvidia 9400M on the logic board. Another non portable computer of mine which uses Nvidia 9300 Go on board graphics runs without such issues. So I expected no reason to worry about the type of graphics chip. Later on, the notebook stopped completely, even without attached external display. It showed a well known one beep every 5 seconds during startup. On MacBook Pro/Air’s this symptom means usually broken RAM.

The RAM is soldered directly on the logic board. Replacing @ Apple appeared prohibitive. Now that I began to look around to sell the broken hardware to hobbyists, I found an article talking about these early MacBook Air’s. This specific one is a 2.1 rev A 2.13 GHz. It was mentioned, that early devices suffered from lead-free soldering, which performs somewhat worse in regards to ductility than normal soldering. The result was that many of these devices suffered from electrical disconnections of its circuitry during the course of warming and cooling and the related thermal expansion and contraction. The device showed the one beep symptom on startup without booting. An engineer from Apple was unofficially cited to suggest, that putting the logic board in around 100° Celsius for a few minutes would eventually suffice to solve the issue. That sounded worth a try to me. As I love to open up many devices to look into and eventually repair them, taking my time for dismounting the logic board and not bringing it to a repair service was fine for me. But be warned, doing so can be difficult for beginners. I placed the board on some wool in the oven @120 ° and after 10 minutes and some more for montage, the laptop started again to work. I am not sure if soldering is really solved now or if the experienced symptoms will come back. I guess that some memory chips on the board were resetted and stopped telling that RAM is broken. So my device works again and will keep us happy for a while – I hope.

http://www.oyranos.org/2015/02/reanimation-of-macbook-air/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:

if [ "$output" = "" ]; then


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


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
Magic Lantern @ LGM in Leipzig http://www.oyranos.org/2014/03/magic-lantern-lgm-in-leipzig/ http://www.oyranos.org/2014/03/magic-lantern-lgm-in-leipzig/#comments Mon, 31 Mar 2014 19:00:04 +0000 oy http://www.oyranos.org/?p=1764 Continue reading ]]> … on Wednesday April 2nd. Their talk will begin 18:30 o’clock local time in the New Paulinum of the University of Leipzig.

Magic Lantern was started in 2009 by Trammel Hudson to bring professional video recording and advanced photographic features to Canon EOS DSLR cameras.

The project expanded and its feature set. Custom video overlays, raw video recording, time lapsed video, manual audio control and more belong to it. With these tools Magic Lantern greatly improved useability in many areas upon bare Canon firmware and is now daily used by many professional photographers, journalists and movie makers.

http://www.oyranos.org/2014/03/magic-lantern-lgm-in-leipzig/feed/ 0
2013 Development Updates http://www.oyranos.org/2014/01/2013-development-updates/ http://www.oyranos.org/2014/01/2013-development-updates/#comments Sun, 26 Jan 2014 15:34:19 +0000 oy http://www.oyranos.org/?p=1746 Continue reading ]]> In presentations I like to use colourful graphics. Some of those graphics are generated automatically by the Cairo based oyranos-profile-graph 2D grapher tool. In git that tool obtained a option to show black body spectra based on kelvin. The spectra are scaled for better illustration.

CIE D65 and black body radiation SPDs for 6500 Kelvin

CIE D65 and black body 6500 Kelvin spectral power distributions (SPD)


Some other work in Oyranos went on with the device mapping to JSON serialisation, as is useful to store device configurations using the Oyranos API. Through JSON files it is possible to support new device classes without to worry about creating a native Oyranos device module. The basic idea is to let users bring in a OpenICC device description and a weighting description. Oyranos is then able to find matches inside its DB and weight the resulting properties according to the provided weighting file. The example code is inside oyranos-test-device and needs still some polishing to become a stable tool. For instance more integration with the frontends and UI parts is needed, to make sure everything gives a nice user experience. Raw images can now be rendered better in image_display and do not show the artefacts from table based conversion of linear camera space to gamma encoded monitor spaces.

During spring 2013 I decided to abstain from public activities and paused coding completely. After some months I was mentally able to enjoy work on self contained stuff. That was first without any community involvement. Months later I contacted some people to explain that situation and want to thank here all those friendly souls who directly encouraged me. After what happened in the last years, I learned, that it can be pretty healthy to not to stay in public light and become involved in highly controversial discussions. Especially the later can become easily burning. As a result of that personal lesson, I skipped 2013 LGM and other meetings and outside activities. Now after around 9 months I feel really better and hope to become slowly more involved. Still I am learning how to keep others opinions at arms length. And that lesson appears key for me to stay welcoming and focused. Well, time will show how well .

Oyranos supports Elektra-0.8.4 in git as a result of friendly behind the scene discussions later in 2013. A new image filter, called “scale“, is currently used inside the image-display example viewer. It does so far no interpolation, but it might become useful for other applications as well, in order to select only a subset of unaltered image pixels. ICC named colour list reading was added. More changes happened around documentation, building external modules and use of threading inside the image-display application.

http://www.oyranos.org/2014/01/2013-development-updates/feed/ 0
Wayland/Weston on oS-12.3 http://www.oyranos.org/2013/04/waylandweston-on-os-12-3/ http://www.oyranos.org/2013/04/waylandweston-on-os-12-3/#comments Sat, 06 Apr 2013 13:07:38 +0000 oy http://www.oyranos.org/?p=1721 Continue reading ]]> After Richards recent patch about adding a colour management system to wayland, I was interested to build a Oyranos CMS connection module for wayland. The patch is in a initial stage, but might get to a similar level like what is already in CompICC and KWin colour servers.

First I substituted all openSUSE-12.3 distro packages with the adequate packages from tobijk and obtained a version 1.0.6 . Keeping the distro Mesa package resulted in a missed EGL Wayland extension and some crashes. On the Wayland website are some instructions on how to setup the environment. Especially the XDG_RUNTIME_DIR variable needs attention. I skipped the part of adding a special weston-lauch group and run the application simply by root. However the a symbol in cairo was missed “cairo_egl_device_create”. After cloning and building pixman and cairo following the Wayland instructions everything went fine. Here a simple ~/.config/weston.ini file to start with:


Weston launches on my system into a multi monitor setup with nouveau. There is still heave tearing, while moving the terminal. After Strg+Alt+Entf (Ctrl+Alt+Del) weston quits.

http://www.oyranos.org/2013/04/waylandweston-on-os-12-3/feed/ 0
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
Lenovo business Sollbruchstelle? http://www.oyranos.org/2013/03/lenovo-business-sollbruchstelle/ http://www.oyranos.org/2013/03/lenovo-business-sollbruchstelle/#comments Fri, 22 Mar 2013 10:48:01 +0000 oy http://www.oyranos.org/?p=1702 Continue reading ]]> One year ago I wrote about the Lenovo Thinkpad Tablet based on Tegra II. After 12 months + the device is now pretty doomed. Not only mechanical switches stop working, the power supply gave up around the same time. Looks like Lenovo sells cheap and crappy hardware for business prices. For a ThinkPad labeled device that is far behind any expectations. But the whole concept behind Lenovos business tablets is flawed.

The manufacturer delivered since quite some time no security updates. The device boots only OS kernels digitally signed by Lenovo. So business administrators can not fix anything on their own as is otherwise usual for Android. That lockout makes just junk in a business environment. Further the company decided to build upon a Windows only chipst for the ThinkPad 2 Tablet, without any plans for migration of investments in Android. The minimum would have been a dual boot machine for those, who prefer to continue with, what they have build already. This is a business reset decision inside Lenovo. One simple measure would be to make the kernel signature public available to allow for security and OS updates on the device on a professional base. An other important step is to open up the currently Windows only ThinkPad 2 tablet for Android.

http://www.oyranos.org/2013/03/lenovo-business-sollbruchstelle/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