[systemsettings] [Bug 225481] Adjust the color temperature of your screen

[Kai-Uwe Behrmann]

https://bugs.kde.org/show_bug.cgi?id=225481

Kai-Uwe Behrmann  changed:

   What|Removed |Added

 Status|UNCONFIRMED |CONFIRMED
 Ever confirmed|0   |1

--- Comment #7 from Kai-Uwe Behrmann  ---
Good to bring this physiological color issue on the table. After more reading
on the subject, personally I support the idea since some months. It is good to
have.

My efforts went into integration of ICC style color management inside the
Oyranos project. Here the page for the Oyranos Night Manager for the
interested:
https://github.com/oyranos-cms/oyranos/projects/2
This implementation will work with old X11, as there are API's easily
available.

There is a different KWin-Wayland effort, which works only for the white point
side without ICC calibration integration or general GPU color transforms.

-- 
You are receiving this mail because:
You are watching all bug changes.

D5928: Introducing Night Color - KWin's native blue light filter at nighttime

[Kai-Uwe Behrmann]

behrmann added a comment.


  In https://phabricator.kde.org/D5928#112398, @subdiff wrote:
  
  > In https://phabricator.kde.org/D5928#112368, @cfeck wrote:
  >
  > > First, the difference between "color management" and "color correction" 
is that color correction is only one step in the color management workflow. 
KWin would need (again) be able to apply color correction to take part in the 
color management workflow. As such, the terms color correction and color 
management can be used interchangeably in the context of KWin discussion.
  > >
  > > Gamma correction (as implemented by the hardware LUTs) cannot be used for 
color correction, because it lacks the cross-component modifications computed 
by the 3x3 matrix or the 3D LUT.
  > >
  > > The term "gamma correction" has been used since decades in the context of 
video cards, even if they are not only used to apply gamma correction, but also 
brigthness/contrast adjustments, color inversion effects, and temperature 
adjustments.
  >
  >
  > Thanks for the explanation in your own words, but there has to be some 
misunderstanding. I wanted to see a quote from a second source besides you ...
  
  
  The 1D gamma business is for proper white point and gray behavior. Most 
people name the 1D LUT stuff "Monitor Calibration". It would be much more clear 
to stick to the "Gamma" or "Calibration" terms here. DRM names it as well 
"drmModeCrtcSetGamma()".
  
  Btw. in terms of ICC the 1D LUT manipulation is called "Calibration" too.

REPOSITORY
  R108 KWin

REVISION DETAIL
  https://phabricator.kde.org/D5928

To: subdiff, #kwin
Cc: behrmann, cfeck, graesslin, davidedmundson, plasma-devel, kwin, ZrenBot, 
spstarr, progwolff, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, 
eliasp, sebas, apol, mart, hein, lukas

[kolor-manager] [Bug 378406] no kcm for setting color management

[Kai-Uwe Behrmann]

https://bugs.kde.org/show_bug.cgi?id=378406

--- Comment #2 from Kai-Uwe Behrmann <k...@gmx.de> ---
kolor-manager-1.0.2 package spec file says libkde4-devel:
https://build.opensuse.org/package/view_file/openSUSE:Leap:42.2/kolor-manager/kolor-manager.spec?expand=1

That is KDE4 and *not* KF5 as used by 42.2. You can try the kolor-manager
*1.1.0* package, which is linked against *KF5*.

See here:
https://software.opensuse.org/package/kolor-manager

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: [Oyranos-devel] [kolor-manager] doc: generate internal documentation from oyranos-policy

[Kai-Uwe Behrmann]

Am 11.04.2017 um 00:17 schrieb Luigi Toscano:
> Luigi Toscano ha scritto:
>> Kai-Uwe Behrmann ha scritto:
>>> Am 07.04.2017 um 14:21 schrieb Luigi Toscano:
>>
>>>> If you want I can fix it.
>>>
>>> Thanks. If you can adapt my changes to better fit the KDE way, that
>>> would be appreciated.
>>>
>>> The german (de_DE) translation is already completed by me. It shows in
>>> regards of language pretty good insight. The czech (cs_CZ) comes from a
>>> photographer with quite some understanding of the topic. It needs only
>>> some few changes.
>>
>> So the plan is roughly:
>> - move the English documentation into the proper place
>> - extract the messages from the localized documents to get gettext files (I'm
>> figuring out a solution, probably some hacking around xml2pot, even if it's
>> not done for that purpose);
>> - remove the translated documents from git (the translated versions will be
>> combined back when creating the release tarballs and they will live, like the
>> other translation artifacts, on SVN).
>> The translators of the six languages should contact the respective 
>> translation
>> teams to contribute the translations.
>>
>> Please don't apply new updates to the documentation until I figure out how to
>> convert the documents into gettext format.
>>
> 
> But, checking the code: what is oyranos-policy? Is the source format a
> different one, and docbook was just an intermediate step? Can we converge to a
> more standard solution (native docbook)? 

The strings reside inside the [Oyranos CMS code][1]. The translations
inside the [po/langXXX.po][2] files there. The texts are used multiple
times as hints etc. inside the various GUI gui's. KHelpCenter is just
one of many text consumers.

The oyranos-policy tool is used for exporting the docbook and HTML
formats on the command line.

(I am not much familiar with docbook. No idea what native docbook implies.)

best regards,
Kai-Uwe

[1]: https://github.com/oyranos-cms/oyranos
[2]: https://github.com/oyranos-cms/oyranos/tree/master/po

Re: [Oyranos-devel] [kolor-manager] doc: generate internal documentation from oyranos-policy

[Kai-Uwe Behrmann]

Am 11.04.2017 um 00:17 schrieb Luigi Toscano:
> Luigi Toscano ha scritto:
>> Kai-Uwe Behrmann ha scritto:
>>> Am 07.04.2017 um 14:21 schrieb Luigi Toscano:
>>
>>>> If you want I can fix it.
>>>
>>> Thanks. If you can adapt my changes to better fit the KDE way, that
>>> would be appreciated.
>>>
>>> The german (de_DE) translation is already completed by me. It shows in
>>> regards of language pretty good insight. The czech (cs_CZ) comes from a
>>> photographer with quite some understanding of the topic. It needs only
>>> some few changes.
>>
>> So the plan is roughly:
>> - move the English documentation into the proper place
>> - extract the messages from the localized documents to get gettext files (I'm
>> figuring out a solution, probably some hacking around xml2pot, even if it's
>> not done for that purpose);
>> - remove the translated documents from git (the translated versions will be
>> combined back when creating the release tarballs and they will live, like the
>> other translation artifacts, on SVN).
>> The translators of the six languages should contact the respective 
>> translation
>> teams to contribute the translations.
>>
>> Please don't apply new updates to the documentation until I figure out how to
>> convert the documents into gettext format.
>>
> 
> But, checking the code: what is oyranos-policy? Is the source format a
> different one, and docbook was just an intermediate step? Can we converge to a
> more standard solution (native docbook)? 

The strings reside inside the [Oyranos CMS code][1]. The translations
inside the [po/langXXX.po][2] files there. The texts are used multiple
times as hints etc. inside the various GUI gui's. KHelpCenter is just
one of many text consumers.

The oyranos-policy tool is used for exporting the docbook and HTML
formats on the command line.

(I am not much familiar with docbook. No idea what native docbook implies.)

best regards,
Kai-Uwe

[1]: https://github.com/oyranos-cms/oyranos
[2]: https://github.com/oyranos-cms/oyranos/tree/master/po

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Oyranos-devel mailing list
Oyranos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oyranos-devel

[kolor-manager] doc/user/po: reduce the docbook links

[Kai-Uwe Behrmann]

Git commit c1298ddf6a0409c49faadc803346b88779cd5a68 by Kai-Uwe Behrmann.
Committed on 08/04/2017 at 19:35.
Pushed by behrmann into branch 'master'.

reduce the docbook links

They where too many. Use "guilabel" elements instead of "sect2" ones.

M  +101  -101  doc/user/po/cs_CZ/docs/kcontrol/kcm_kmsettings/index.docbook
M  +100  -100  doc/user/po/de_DE/docs/kcontrol/kcm_kmsettings/index.docbook
M  +100  -100  doc/user/po/en_US/docs/kcontrol/kcm_kmsettings/index.docbook
M  +100  -100  doc/user/po/eo/docs/kcontrol/kcm_kmsettings/index.docbook
M  +100  -100  doc/user/po/eu/docs/kcontrol/kcm_kmsettings/index.docbook
M  +100  -100  doc/user/po/fr_FR/docs/kcontrol/kcm_kmsettings/index.docbook
M  +100  -100  doc/user/po/ru_RU/docs/kcontrol/kcm_kmsettings/index.docbook

https://commits.kde.org/kolor-manager/c1298ddf6a0409c49faadc803346b88779cd5a68

diff --git a/doc/user/po/cs_CZ/docs/kcontrol/kcm_kmsettings/index.docbook 
b/doc/user/po/cs_CZ/docs/kcontrol/kcm_kmsettings/index.docbook
index ecff230..12cc26d 100644
--- a/doc/user/po/cs_CZ/docs/kcontrol/kcm_kmsettings/index.docbook
+++ b/doc/user/po/cs_CZ/docs/kcontrol/kcm_kmsettings/index.docbook
@@ -48,7 +48,7 @@ Internet: http://www.oyranos.org;>www.oyranos.org
   
 

-Oyranos is a Color Management System (CMS), which relies one the ICC file 
format standard (http://www.color.org;>www.color.org) for 
color space definitions. The use of ICC color profiles shall enable a flawless 
and automated color data exchange between different color spaces and various 
devices with their respective physical color behaviours. 
+Oyranos je systém pro správu barev (CMS), který využívá jeden ze standardů 
souborového formátu ICC (http://www.color.org;>www.color.org) pro definice barvových 
prostorů. Použití barvových profilů ICC má umožnit bezproblémovou a 
automatizovanou výměnu dat o barvách mezi různými barvovými prostory a různými 
zařízeními s ohledem na jejich schopnost reprodukce barev. 
   
 

@@ -67,125 +67,125 @@ Oyranos allowes detailed settings like preferred editing 
color spaces and the be
 
   Výchozí profily
   Profily ICC by vždy měly být přiřazeny ke všem barvám. Pro 
nedefinované barvy mohou uživatelé nastavit různé výchozí profily ICC v 
nastaveních Oyranosu.
-
-  Editace XYZ
-  Preferovaný barvový prostor editace XYZ by měl popisovat 
CIE*XYZ.
-
-
-  Editace Lab
-  Preferovaný barvový prostor editace CIE*Lab by měl popisovat 
CIE*Lab.
-
-
-  Editace RGB
-  Preferovaný barvový prostor editace RGB by měl popisovat dobře se 
chovající barvový prostor jako např. sRGB.
-
-
-  Editace CMYK
-  Preferovaný barvový prostor editace CMYK by měl popisovat barvový 
prostor, který je kompatibilní s dobře definovaným standardem jako např. FOGRA 
či SWOP.
-
-
-  Editace v šedi
-  Preferovaný barvový prostor editace v šedi by měl popisovat 
barvový prostor s jedním kanálem jasu pro monochromatické obrázky.
-
-
-  Předpokládaný vstupní XYZ
-  Vybraný barvový prostor bude přiřazen k neoznačeným barvám modelu 
XYZ a definuje barvy pro další zpracování.
-
-
-  Předpokládaný vstupní Lab
-  Vybraný barvový prostor bude přiřazen k neoznačeným barvám modelu 
CIE*Lab a definuje barvy pro další zpracování.
-
-
-  Předpokládaný vstupní RGB
-  Vybraný barvový prostor bude přiřazen k neoznačeným barvám RGB a 
definuje barvy pro další zpracování.
-
-
-  Předpokládaný vstupní Web
-  Přiřadí tento barvový prostor neoznačenému obrázku RGB 
pocházejícího z WWW. Toto bude vždy sRGB dle definice W3C.
-
-
-  Předpokládaný vstupní CMYK
-  Vybraný barvový prostor bude přiřazen k neoznačeným barvám CMYK a 
definuje barvy pro další zpracování.
-
-
-  Předpokládaný pr. vstup. šedi
-  Vybraný barvový prostor bude přiřazen k neoznačeným barvám modelu 
Gray (šeď) a definuje odstíny pro další zpracování.
-
+
+Editace XYZ 
+Preferovaný barvový prostor editace XYZ by měl popisovat 
CIE*XYZ.
+
+
+Editace Lab 
+Preferovaný barvový prostor editace CIE*Lab by měl popisovat 
CIE*Lab.
+
+
+Editace RGB 
+Preferovaný barvový prostor editace RGB by měl popisovat dobře se 
chovající barvový prostor jako např. sRGB.
+
+
+Editace CMYK 
+Preferovaný barvový prostor editace CMYK by měl popisovat barvový 
prostor, který je kompatibilní s dobře definovaným standardem jako např. FOGRA 
či SWOP.
+
+
+Editace v šedi 
+Preferovaný barvový prostor editace v šedi by měl popisovat barvový 
prostor s jedním kanálem jasu pro monochromatické obrázky.
+
+
+Předpokládaný vstupní XYZ 
+Vybraný barvový prostor bude přiřazen k neoznačeným barvám modelu 
XYZ a definuje barvy pro další zpracování.
+
+
+Předpokládaný vstupní Lab 
+Vybraný barvový prostor bude přiřazen k n

Re: [kolor-manager] doc: generate internal documentation from oyranos-policy

[Kai-Uwe Behrmann]

Am 07.04.2017 um 14:21 schrieb Luigi Toscano:
> On Friday, 7 April 2017 14:04:22 CEST Kai-Uwe Behrmann wrote:
>> Git commit 540843bc23d52c1b84369ff7ad0d0910f64f4f97 by Kai-Uwe Behrmann.
>> Committed on 07/04/2017 at 09:41.
>> Pushed by behrmann into branch 'master'.
>>
>> generate internal documentation from oyranos-policy
>>
>> The Oyranos tool exports all needed strings in docbook format for
>> different languages. cs, de and en should be fine.
>>
>> A unix environment is experected for the "make generate" targets.

> is this internal documentation? It seems the documentation of a KCM.

yes and yes

> Please follow the standard practice of the community: don't commit the 
> translated documentation directly but let translation teams handle it. Just 
> commit the English version, which does not need to be so nested or it would 
> make the life of few extraction scripts more complicated, and add the 
> translated docbooks to the tarball at release time.

Ah, I was searching for a tutorial but did not find too much of it.

> If you want I can fix it.

Thanks. If you can adapt my changes to better fit the KDE way, that
would be appreciated.

The german (de_DE) translation is already completed by me. It shows in
regards of language pretty good insight. The czech (cs_CZ) comes from a
photographer with quite some understanding of the topic. It needs only
some few changes.

best regards
Kai-Uwe

[kolor-manager] doc: generate internal documentation from oyranos-policy

[Kai-Uwe Behrmann]

Git commit 540843bc23d52c1b84369ff7ad0d0910f64f4f97 by Kai-Uwe Behrmann.
Committed on 07/04/2017 at 09:41.
Pushed by behrmann into branch 'master'.

generate internal documentation from oyranos-policy

The Oyranos tool exports all needed strings in docbook format for
different languages. cs, de and en should be fine.

A unix environment is experected for the "make generate" targets.

A  +1-0doc/CMakeLists.txt
A  +27   -0doc/user/CMakeLists.txt
A  +191  -0doc/user/po/cs_CZ/docs/kcontrol/kcm_kmsettings/index.docbook
A  +191  -0doc/user/po/de_DE/docs/kcontrol/kcm_kmsettings/index.docbook
A  +191  -0doc/user/po/en_US/docs/kcontrol/kcm_kmsettings/index.docbook
A  +191  -0doc/user/po/eo/docs/kcontrol/kcm_kmsettings/index.docbook
A  +191  -0doc/user/po/eu/docs/kcontrol/kcm_kmsettings/index.docbook
A  +191  -0doc/user/po/fr_FR/docs/kcontrol/kcm_kmsettings/index.docbook
A  +191  -0doc/user/po/ru_RU/docs/kcontrol/kcm_kmsettings/index.docbook

https://commits.kde.org/kolor-manager/540843bc23d52c1b84369ff7ad0d0910f64f4f97

diff --git a/doc/CMakeLists.txt b/doc/CMakeLists.txt
new file mode 100644
index 000..6cc2307
--- /dev/null
+++ b/doc/CMakeLists.txt
@@ -0,0 +1 @@
+ADD_SUBDIRECTORY(user)
diff --git a/doc/user/CMakeLists.txt b/doc/user/CMakeLists.txt
new file mode 100644
index 000..2dc622f
--- /dev/null
+++ b/doc/user/CMakeLists.txt
@@ -0,0 +1,27 @@
+SET( GENERATOR /home/kuwe/.local/bin/oyranos-policy -vvv )
+SET( DOCBOOK_BASE ${CMAKE_CURRENT_SOURCE_DIR}/po )
+SET( DOCBOOK_AFTER docs/kcontrol/kcm_kmsettings )
+
+FOREACH(lang en_US ${OYRANOS_LINGUAS_FULL})
+  ADD_CUSTOM_TARGET( generate-${lang}
+  COMMAND mkdir -p ${DOCBOOK_BASE}/${lang}/${DOCBOOK_AFTER}
+  COMMAND echo "LANG=${lang}.UTF-8 ${GENERATOR} --docbook --doc-title 
KolorManager KCM --doc-version ${${PROJECT_NAME}_VERSION} > 
${DOCBOOK_BASE}/${lang}/${DOCBOOK_AFTER}/index.docbook"
+  COMMAND LANG=${lang}.UTF-8 ${GENERATOR} --docbook --doc-title 
"KolorManager KCM" --doc-version ${${PROJECT_NAME}_VERSION} > 
${DOCBOOK_BASE}/${lang}/${DOCBOOK_AFTER}/index.docbook
+  COMMENT generate KDE help files in docbook format
+  VERBATIM
+  )
+  SET( GENS ${GENS} generate-${lang} )
+ENDFOREACH()
+
+ADD_CUSTOM_TARGET( generate
+   COMMAND echo "generated following linguas: ${OYRANOS_LINGUAS_FULL}"
+   DEPENDS ${GENS}
+   COMMENT generate docbook KDE help files
+   VERBATIM
+   )
+
+# install docbook for all available languages
+KDOCTOOLS_INSTALL(po)
+
+# install a single language docbook
+#kdoctools_create_handbook(index.docbook INSTALL_DESTINATION 
${KDE_INSTALL_DOCBUNDLEDIR}/en SUBDIR kcontrol/kcm_kmsettings)
diff --git a/doc/user/po/cs_CZ/docs/kcontrol/kcm_kmsettings/index.docbook 
b/doc/user/po/cs_CZ/docs/kcontrol/kcm_kmsettings/index.docbook
new file mode 100644
index 000..ecff230
--- /dev/null
+++ b/doc/user/po/cs_CZ/docs/kcontrol/kcm_kmsettings/index.docbook
@@ -0,0 +1,191 @@
+
+KolorManager KCM">
+
+
+
+]>
+ 
+ 
+    Oyranos User Manual 
+ 
+     
+ 
+Kai-Uwe 
+Behrmann 
+ 
+k...@gmx.de 
+ 
+         
+     
+ 
+ 
+2017 
+Kai-Uwe Behrmann 
+ 
+ 
+2017-04-05 
+ 
+ 
+ 
+This is the documentation for the  that configures the 
Oyranos Color Management System. 
+ 
+ 
+ 
+KDE 
+System Settings 
+Oyranos 
+Color Management 
+KolorManager 
+Synnefo 
+ 
+ 
+
+   
+ Introduction
+  
+Internet: http://www.oyranos.org;>www.oyranos.org 
+  
+
+   
+Oyranos is a Color Management System (CMS), which relies one the ICC file 
format standard (http://www.color.org;>www.color.org) for 
color space definitions. The use of ICC color profiles shall enable a flawless 
and automated color data exchange between different color spaces and various 
devices with their respective physical color behaviours. 
+  
+
+   
+Mapování barev mezi různými zařízeními je možné za předpokladu, že známe 
barvovou charakteristiku dotčených zařízení. Kvalita transformace barev pro 
zařízení z jednoho barvového prostoru do druhého závisí zvláště na kvalitě 
měření barev a charakterizačních algoritmů použitých při přípravě profilu ICC. 
Definice každého barvového prostoru obsahuje referenci na tzv. propojovací 
prostory (PCS). PCS je dobře známý barvový prostor založený na průměrném 
"lidském pozorovateli" dle definice CIE. 
+  
+
+   
+Barvové profily jsou poskytnuty výrobci obrazových zařízení jako jsou 
digitální fotoaparáty, monitory a tiskárny. V Oyranosu jsou profily ICC 
přiřazeny ke kalibrovaným stavům jednotlivých zařízení, aby se zajistilo shodné 
chování zařízení jako při přípravě profilu ICC. 
+  
+
+   
+Oyranos allowes

[Oyranos-devel] ANNOUNCE KolorManager+Synnefo 1.1.0 released

[Kai-Uwe Behrmann]

This is a feature and bug fix release. KolorManager wiped off its core
and reimported it by libOyranosSynnefo.

New Features

* port core to libOyranosSynnefo
* port to Qt5/KF5
* add Settings::Effect tab
* send native update events on changes to update color server
* [watch libelektra D-Bus update messages][1] and update device list

Bug Fixes
=
* fix multibyte string display
* fix showing 2D graph without ICC Examin
* do not set a device profile unquestioned; just view

ChangeLog and Download
==

https://github.com/KDE/kolor-manager/


Synnefo 1.1.0
=

This is the initial release of the Qt based Synnefo project. It contains
the GUI library libOyranosSynnefo for embedding into Qt UIs and the
standalone oyranos-config-synnefo GUI, which can run on several desktops
and OSes.

This is the initial release of the Qt based Synnefo project. It contains the
GUI library libOyranosSynnefo for embedding into Qt UIs and the standalone
oyranos-config-synnefo GUI, which can run on several desktops and OSes.

Features

* support [Oyranos][1] settings and devices
* support [online ICC Taxi DB][2] for device profile installation
* port code from KDEs KolorManager
* port to Qt5
* port to OS X framework
* add Settings::Effect tab
* send native update events on changes to update color server
* [watch libelektra D-Bus update messages][3] and update device list

Bug Fixes
=
* fix multibyte string display
* fix showing 2D graph without ICC Examin
* do not set a device profile unquestioned; just view

[1]: http://www.oyranos.org/about
[2]: http://www.oyranos.org/taxi/
[3]: http://www.oyranos.org/2016/11/watching-org-libelektra-with-qt/

ChangeLog and Download
==

https://github.com/oyranos-cms/synnefo

Thanks to all contributors and bug reporters.

regards
Kai-Uwe Behrmann
-- 
www.behrmann.name + www.oyranos.org



--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
Oyranos-devel mailing list
Oyranos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oyranos-devel

[Oyranos-devel] ANNOUNCE: Oyranos 0.9.6 released

[Kai-Uwe Behrmann]

This release is a bugfix and feature release. The non standard core
dependencies are plain included for easy building and faster porting.
Testing, code documentation and tutorials have improved. This version is
not fully API compatible with previous releases in order to support
many new features.

New features

Core

* improved image ROI support for scaling, with many new APIs
* add [CMM selection API][1] and many related API changes
* support effect filter configuration with OY_PROFILES_EFFECT key and
oyWIDGET_PROFILE_EFFECT
* add [threads hooks][2], with defaults loaded from pthreads + win32
threads module "trds"
* abstract DB dependency out
* add DB cache for faster repeated access, clearing the cache is done by
calling oyGetPersistentStrings(NULL)
* add oySCOPE_e and use in DB related APIs
* add JSON device load APIs with oyDeviceFrom/ToJSON()
* [create device filter on the fly from rank map][3] using JSON files
* add oyOptions_FromJSON()/oyOptions_GetText(oyNAME_JSON) APIs
* add introspection framework for object to SVG dumps; see
[oyObjectTreePrintf()][4]
* add [oyProfile_FromName()][5] supporting file name, internal profile
names, ICC ID and wildcard names for use in tools
* filter duplicates in oyProfiles_Create() and support
OY_ALLOW_DUPLICATES flag
* add oyGetInstallPath() and oyProfile_Install() APIs

Tools
-
* add profile version selectors (-2|-4)
* support profile names like file/ID/md5/default profile wildcards for
profile arguments
* add profile --path and --short options to better pass profiles to
other tools
* add *oyranos-policy -cfe* options to show current policy file name
* support [OY_DEBUG_OBJECTS environment variable][6] for code
introspection, writes the object tree as SVG
* [support Qt5][7] by *qcmsevents* tool
* support SVG output in *oyranos-profile-graph*, beside PNG
* open graph window after tools exit, needs set OY_DEBUG_OBJECTS
* improve *oyranos-monitor-daemon* session daemon by syncing X root
window, XRandR and Gnome profiles

Modules
---
* new “trds” default threads module, with POSIX pthreads and windows
threads support
* new “elDB” / Elektra and "oiDB" modules , default loaded DB hooks from
["elDB" / Elektra][8] if available and a fallback to included
[libOpenICC][9]
* add [oyMonitorHooks_s interface][10] to write system specific monitor
hooks independently and easily
* support [EDID_md5 and EDID meta keys][11] in disp module family for
compatibility
* add "move_color_server_profiles._oyX1" and "clean_profiles._oyX1"
handler filters used so far by *oyranos-monitor-daemon* and *CompICC*
* add oyCMM_s.h header to build modules out of tree
* support [HALF reading in PPM][12] image reader
* add "oJPG" JPEG image reader
* add "scale", "expose" and "channel" filters in "oyra" module

Examples

* add more tutorials and examples and link them in the inline documentation
* support High-DPI monitors in all FLTK based GUIs

**oyranos-image-display**
* support scaling [+,-,w,h,0,1, mouse scroll], channel selection [0-9
keys] and exposure  [Alt +,-,.]
* support image flipping [<,>]
* support full screen view [Alt v,F11]
* add help [F1] and shortcut help view (Ctrl H)
* add image info window [Ctrl F]
* support view of oyHALF and oyDOUBLE sample types
* support view of object tree with set OY_DEBUG_OBJECTS + Ctrl q in
Firefox, The graph can be rather big.
* make options editor [Ctrl E] selectable with OY_OFORMS_RENDERER
variable, default is still oyranos-xforms-fltk

**oyranos-config-fltk**
* show CMM selection tab by libOyranos changes
* show Effect selection by libOyranos changes

Compiling
-
* remove cores hard dependency on libelektra, for instant compiling and
at a cost of no [D-Bus messages][13]
* include light weight libOpenICC for the default fallback DB handler
"oiDB"; The system library can be enforced with cmake
-DUSE_SYSTEM_OPENICC switch, similar to USE_SYSTEM_YAJL switch
* relax dependency on external libXcm; The system library can be
enforced with cmake -DUSE_SYSTEM_LIBXCM switch
* compile in [Travis CI][14] with no additional dependencies
* compile "SANE" module by default; The rank map is in a separately
installed file.
* compile Qt4 and Qt5 tool versions in the same build
* build [OS X Frameworks][15] and rename library names to camel case

Bug Fixes
=
* known bugs are fixed, except a [multi-monitor display related
one][16], which is stalled to the next release
* many new tests where added to cover more old and new test cases
* use prelinearised curves by default in lcms modules to fix gamma 1.0
viewing
* use no adapt to white point by default in lcms modules to fix strange
white viewing with effects
* [Rename URI: bsd-license.php -> BSD-3-Clause][17]
* allow view of defect profiles in analysis tools without repair

ChangeLog and Download
==
http://github.com/oyranos

[kolor-manager] [Bug 347154] No monitor profile color management possible in Plasma5!

[Kai-Uwe Behrmann]

https://bugs.kde.org/show_bug.cgi?id=347154

Kai-Uwe Behrmann <k...@gmx.de> changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Kai-Uwe Behrmann <k...@gmx.de> ---
KolorManager 1.1.0 with KF5 support was released

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: [Lcms-user] LCMS soft proofing options and PhotoShop's simulate black ink and paper

[Kai-Uwe Behrmann]

Am 19.05.2016 um 14:10 schrieb Elle Stone:
> On 05/19/2016 02:03 AM, Kai-Uwe Behrmann wrote:
> So there wasn't an equivalent Cinepaint option for "simulate black ink"?
> (If there's a way to compile Cinepaint on Gentoo, I haven't found it.)

I never thought about that. Oyranos git should be in Gentoo. At least we
obtain patches from Gentoo.

> Did/does the Cinepaint/Oyranos
> "simulate paper" match the PhotoShop "simulate paper"?

Back when implementing that stuff, I checked visually with lots of
prints and light both comparisons and found satisfying results in
CinePaint. However, my goal was not to blindly follow PhotoShop. So no
guarantee for identical output.

kind regards
Kai-Uwe

--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] LCMS soft proofing options and PhotoShop's simulate black ink and paper

[Kai-Uwe Behrmann]

Am 18.05.2016 um 21:16 schrieb Elle Stone:
> Can LCMS be used to provide soft proofing options like PhotoShop's 
> "simulate black ink" and "simulate paper"?
> 
> I seem to remember seeing similar options in Cinepaint, which used LCMS 
> version 1. But looking in the Cinepaint code, all I see is this:
> 
> menus_set_state ("/View/Simulatate Paper", gdisp->cms_proof_flags 
> ==INTENT_ABSOLUTE_COLORIMETRIC);

For the lcms2 API one needs to set the adaption state as well in order
to obtain a monitor to light both match. That way the
oyranos-image-display viewer shows the same result like with lcms1.

kind regards
Kai-Uwe

--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Oyranos-devel] effect + cmm settings in Synnefo GUI

[Kai-Uwe Behrmann]

Joseph, thanks for the hint.

The effect settings are added and simulation has joined in the new
effect tab. For the moment I keept CMM settings off Synnefo as it is not
of much use so far. And people who like to experiment, can use the
oyranos-config-fltk.

Here are some newer screenshots:
http://www.oyranos.org/images/oyranos-config-synnefo_behaviour-tab-0.9.6.jpg
http://www.oyranos.org/images/oyranos-config-synnefo_effect-tab-0.9.6.jpg

Kai-Uwe

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
Oyranos-devel mailing list
Oyranos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oyranos-devel

[Oyranos-devel] effect + cmm settings in Synnefo GUI

[Kai-Uwe Behrmann]

Hello,

the example config dialog oyranos-config-fltk obtained during the last
development cycle (0.9.6) two new tabs. The CMM tab for CMM selection
and the effect tab for setting and activating a effect profile. Both are
supported by the core and pretty usful in desktop color servers and viewers.

However the Synnefo GUI (oyranos-config-synnefo) uses a much more
compact layout. Now, where to add the new settings in Synnefo? Currently
there are following tabs in Settings: Policy, Default Profiles and
Behaviour. Comments are welcome.

Here some current screenshots:
http://www.oyranos.org/images/oyranos-config-fltk_effect-tab-0.9.6.jpg
http://www.oyranos.org/images/oyranos-config-fltk_cmm-tab-0.9.6.jpg
http://www.oyranos.org/images/oyranos-config-synnefo_behaviour-tab-0.9.5.jpg

Kai-Uwe

--
___
Oyranos-devel mailing list
Oyranos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oyranos-devel

Re: [CREATE] Fw: [scribus] Swatchbooker project needs some help

[Kai-Uwe Behrmann]

Am 16.01.2016 um 09:59 schrieb Boudewijn Rempt:
>> https://phabricator.kde.org/T112
> The link should be open now... Phabricator is still a bit experimental.

thanks

> By the way, on the subject of resources -- I'd really like to move to a
> more modern resource format for everything, one that includes at least a
> GUID for every resource.

In the next ICC spec will be floating point colour lists possible. But I
did not much follow the details recently. That's why I cross post to the
ICC experts.
___
CREATE mailing list
CREATE@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/create

[systemsettings] [Bug 357688] New: DPI is always reported to 96 on High Res Display

[Kai-Uwe Behrmann via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357688

Bug ID: 357688
   Summary: DPI is always reported to 96 on High Res Display
   Product: systemsettings
   Version: 5.4.3
  Platform: openSUSE RPMs
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: kcm_fonts
  Assignee: unassigned-b...@kde.org
  Reporter: k...@gmx.de
CC: unassigned-b...@kde.org

The plasma 5 systemsettings fontsettings panel has a checkbox for forcing a DPI
value for fonts and a accompanying DPI value field. So far so good.

On a MacBook-pro with retina display this field is always set to 96 DPI, which
is wrong. This setting forces me to adjust the value manually to 192 doubling
the size to obtain a reasonable desktop. The correct physical DPI value is 227.

After some research for other non Qt based applications, I found that 96 is
always reported by Xinerama on this machine, with all other values like size
and so on computed to match 96 DPI. However XRandR reports the size in
millimeter correctly. Based on this information and the desktops pixel size,
the DPI can be computed correctly.

Reproducible: Always

Steps to Reproduce:
1. install KDE Plasma 5 on MacBookPro Retina
2. see the too small desktop windows rendering
3. go to systemsettings -> font settings -> force DPI box

Actual Results:  
see 96 DPI in the fonts force DPI value box

Expected Results:  
see the xrandr reported DPI value in the fonts force DPI value box

// Here some code showing the correct DPI values by using the XRandR API.
// Hope this helps.
// cc -Wall -g -pedantic XRandRfl.cxx -o XRandRfl -lX11 `pkg-config --libs
xrandr`
#include 
#include 

int main(int argc, char ** argv)
{
  Display * display = XOpenDisplay(":0.0");
  int screen = DefaultScreen( display );
  Window w = RootWindow(display, screen);
  XRRScreenResources * res = XRRGetScreenResources(display, w);
  for(int i=0; i < res->noutput; ++i)
  {
XRROutputInfo * output_info = XRRGetOutputInfo( display, res,
res->outputs[i]);
if(output_info->crtc)
{
  XRRCrtcInfo * crtc_info = XRRGetCrtcInfo( display, res,
output_info->crtc );
  unsigned int pixel_width = crtc_info->width,
   pixel_height = crtc_info->height;
  float xdpi = pixel_width * 25.4f / (float)output_info->mm_width,
ydpi = pixel_height * 25.4f / (float)output_info->mm_height;
  printf( "[%d] %upx x %upx  Dimensions: %limm x %limm  DPI: %.02f x
%.02f\n",
  i, pixel_width, pixel_height,
  output_info->mm_width, output_info->mm_height,
  xdpi, ydpi );
}
XRRFreeOutputInfo( output_info );
  }
  XRRFreeScreenResources(res);
  XCloseDisplay( display );

  return 0;
}

-- 
You are receiving this mail because:
You are watching all bug changes.

[systemsettings] [Bug 357688] DPI is always reported to 96 on High Res Display

[Kai-Uwe Behrmann via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357688

Kai-Uwe Behrmann <k...@gmx.de> changed:

   What|Removed |Added

 CC||k...@privat.broulik.de

-- 
You are receiving this mail because:
You are watching all bug changes.

[systemsettings] [Bug 357688] DPI is always reported to 96 on High Res Display

[Kai-Uwe Behrmann via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357688

Kai-Uwe Behrmann <k...@gmx.de> changed:

   What|Removed |Added

 CC||k...@gmx.de

-- 
You are receiving this mail because:
You are watching all bug changes.

[systemsettings] [Bug 357688] DPI is always reported to 96 on High Res Display

[Kai-Uwe Behrmann via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357688

--- Comment #1 from Kai-Uwe Behrmann <k...@gmx.de> ---
The offending line is here:
https://quickgit.kde.org/?p=plasma-desktop.git=blob=07297bb660e4fd16059978f3b0e539d377542de0=6367245d25d521d498d1b0734f88d287e17e69b1=kcms%2Ffonts%2Ffonts.cpp
line:710

#if HAVE_X11
checkboxForceDpi->setChecked(false);
spinboxDpi->setValue(96);
#endif

-- 
You are receiving this mail because:
You are watching all bug changes.

[systemsettings] [Bug 357688] DPI is always reported to 96 on High Res Display

[Kai-Uwe Behrmann via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357688

--- Comment #3 from Kai-Uwe Behrmann <k...@gmx.de> ---
Where does this default of 96 DPI come from? Why not 72 DPI why not assume
actual display resolution of 192 or 300dpi? 

"Scale Display" in the display section does not affect font renderings -
unfortunately. It would be cool if it allows scaling with one setting. Instead
now (5.4.3) users are forced to do three settings to adapt the desktop scaling:
* set "Force fonts DPI:" and assign a proper DPI value
* set "Scale Display" scale factor - not dpi: sig
* set tool bar height outside of systemsettings again in a different unit -
pixels

-- 
You are receiving this mail because:
You are watching all bug changes.

[systemsettings] [Bug 357688] DPI is always reported to 96 on High Res Display

[Kai-Uwe Behrmann via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357688

Kai-Uwe Behrmann <k...@gmx.de> changed:

   What|Removed |Added

Version|5.4.3   |5.5.2

--- Comment #9 from Kai-Uwe Behrmann <k...@gmx.de> ---
(In reply to Kai-Uwe Behrmann from comment #7)
> (In reply to Kai Uwe Broulik from comment #4)
> > The screen scaling settings also change Xft dpi, the same settings the force
> > fonts dpi influences.
> 
> Oh, that's then perhaps newer than the code I could test. Would be great.

The screen scaling of kscreen does not handle any font, just window and icon
sizes.
I tested with kscreen 5.5.2 in KF-5.17.

-- 
You are receiving this mail because:
You are watching all bug changes.

[systemsettings] [Bug 357688] DPI is always reported to 96 on High Res Display

[Kai-Uwe Behrmann via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357688

--- Comment #6 from Kai-Uwe Behrmann <k...@gmx.de> ---
"Kontrollleiste" is it called in KDE/german. Dock in OS X. "Taskleiste" in
Windows/german.

-- 
You are receiving this mail because:
You are watching all bug changes.

[systemsettings] [Bug 357688] DPI is always reported to 96 on High Res Display

[Kai-Uwe Behrmann via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=357688

--- Comment #7 from Kai-Uwe Behrmann <k...@gmx.de> ---
(In reply to Kai Uwe Broulik from comment #4)
> The screen scaling settings also change Xft dpi, the same settings the force
> fonts dpi influences.

Oh, that's then perhaps newer than the code I could test. Would be great.

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: Color Management

[Kai-Uwe Behrmann]

Am 21.09.2015 um 19:26 schrieb Martin Kaffanke:
> Is there a way to make colors on the display looking the same as on the 
> printer, by printing a Page and compare the screen on sight? 

You can check if KolorManager[1] finds a profile for your monitor in
Taxi DB[2] and install that. KDE's KWin has color correction build in[3].

Hope this helps you on the display side.

kind regards
Kai-Uwe
-- 
www.oyranos.org

[1] http://www.oyranos.org/kolormanager/
[2] http://www.oyranos.org/taxi/
[3] https://userbase.kde.org/Color_Management
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: [Lcms-user] Obtaining a linear variety of an arbitrary icc profile.

[Kai-Uwe Behrmann]

Am 19. September 2015 15:01:18 MESZ, schrieb Wolthera :

>I sent a mail back in august about retrieving data from an icc profile.
>In
>the case of Linearising a given colour value from a gamma corrected
>space
>for the use in filters, the following was suggested:
>
>1. Get a linear version of the same profile.
>2. Convert with LCMS to that profile and back when you're done.
>
>Problem is, how does one obtain this linear profile when expecting any
>arbitrary icc profile?

Obtaining a linear version is indeed not practical. Working spaces are mostly 
matrix shaper profile. From there might come the assumtion that creating a 
linear version of such profile is almost trivial. But table based profiles are 
similarily possible - and then obtaining a linear version is not trivial.

>There's something of an 'linearisation device
>link'
>mentioned in the API docs, but it doesn't mention how to use this, so I
>can't verify if this is the function that I am looking for.

Linearisaton profiles are created from per channel measurements to bring a 
press in good profiling condition. It is as well used to keep print conditions 
stable according ro measurements. So that is not exactly your case ;-)

>The second option is to have LCMS customly make a profile from the data
>of
>the abitrary profile, but this seems very error-prone?

You will need much effort to get that right.

>Option 3 is to have several hard-coded rgb spaces, which is also quite
>awkward.

It would have its merits. You can then clearly define how a given filter will 
work and process in linear space without clipping

>What would be the best way to solve this?

I guess you need to discuss if *all* filters shall work in each space 
differently. For curve based filters I would assume yes, each space shall work 
differently for per channel curve operations (e.g. curve tool). For such tools 
you do not need to colour convert/work in linear space. For doing a 
desaturation effect users might simply expect a neutral desaturation regardless 
of the underlying colorspace. For blending effects, I would assume CIE*XYZ 
(with linear gamma, processed as floating point precission) will give most 
relyable/repeatable results.

So, sorry, no one single answere. More a - it depends on the situation.
kind regards
Kai-Uwe

--
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] Fwd: Trying to make a UI for colorspaces, have some questions.

[Kai-Uwe Behrmann]

Am 29.08.2015 um 21:54 schrieb Wolthera:
 On Sat, Aug 29, 2015 at 7:42 PM, marti.ma...@littlecms.com wrote:
 Regarding the question on gamut, the good way to represent a gamut is by
 using a 3D solid, just because our vision have 3 cones that gives us three
 dimensions. The tonge chromaticity diagram can give an idea of the
 primaries, but does not explain how the gray axis affects the color.

 I know that, but right now a lot of artists already find the color
 management terrifying, displaying a 3d gamut would be something I would
 like postpone until the general krita-user community has gotten used to the
 idea that colors have spaces. I've already had a lot of people freak out at
 the notion of giving an explanation of what certain properties mean for a
 profile, and this is outside the reactions we get on Krita having profiles
 at all(after all, there's no need for anything besides a radio button box
 with 'RGB' and 'CMYK' for proper artists according to these people). I
 imagine giving people a 3d color gamut at this current stage will cause
 heart-attacks. Still, it seems the same kind of problems need to be solved
 anyhow.

Just imagine at how Krita will want to present colour spaces in 3D
(hint: CIE*Lab) and implement a 2D CIE*Lab graph for now.

 A way to paint the gamut would be to use the AtoB1 tag, transform a coarse
 sampling of all RGB or CMYK space and then use some sort of convex hull
 algorithm, or alpha shapes, to build the solid on Lab. This may also work
 for the tonge, it is just a matter of converting to xyY and take the xy
 coordinates. Making a color transform from the profile to XYZ identity does
 most of the work. Then there is a function to convert XYZ - xyY.


 Okay, so you are suggesting I try to take a set of colors, generated spaced
 out over the different channels(so if I were to make 10 samples per
 channel, RGB would give me 10³ colors and CMYK would give me 10⁴ colors...
 perhaps a bit too many samples). Then transform those colors to XYZ(using
 relative colorimetric mapping as indicated by your suggestion of the AtoB1
 tag), then to xyY, find the outliers, draw a polygon around them, and then
 use that to give feedback on the gamut?

In Oyranos is a more simple approch implemented [1]. This tool generates
a saturation line going around from the primary colours over the
secondary ones (R-RG-G-GB-B-BR-R ; same for Cmyk) and convert that
through the according RGB or Cmyk profile to CIE*Lab. The CIE*Lab
colours can then directly drawn as coordinates to the 2D graph. All math
is integer based to get the desired clipping.

-- 
kind regards
Kai-Uwe

www.oyranos.org

[1] search for oyranos-profile-graph; It is used in KolorManager and ICC
Examin

--
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Oyranos-devel] Oyranos on Plasma 5

[Kai-Uwe Behrmann]

Am 06.05.2015 um 19:06 schrieb Casian Andrei:
 For KDE Frameworks 5 and Plasma 2 one would need the yet
 (unfortunately) under test color correction brach for kwin
 (frameworks) and the new (unfortunately) under test kolor-server
 (frameworks).

 These can be found at:
 Konsole output
 git://anongit.kde.org/clones/kwin/casianandrei/kwin-color

 Konsole output
 g...@git.kde.org:scratch/casianandrei/kolor-server

 If you can help out with the testing, it would be great.

I only tested building kolor-server on Plasma, which is fine.

 On 05/04/15 23:37, Kai-Uwe Behrmann wrote:
 or Plasma 5, I have not much glue how to build or test under. Oyranos
 itself is DE agnostic. The display module needs X11/XRandR running. For
 KolorManager I do not know what is needed to run in Plasma, if that DE
 is too different this front end might fail to build. However one can use
 Oyranos/Synnefo from git for this part. Casian can likely tell more

Synnefo builds with qt5. And I have a local kcmshell5 kmdevice. As the
other KCM modules are very thin it is not much work to complete. However
Synnefo needs some work to run with qt4 and qt5. more on that in an
other thread.

kind regards
Kai-Uwe


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Oyranos-devel mailing list
Oyranos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oyranos-devel

Re: [Oyranos-devel] Oyranos on Plasma 5

[Kai-Uwe Behrmann]

Am 08.05.2015 um 11:27 schrieb Kai-Uwe Behrmann:
 Synnefo builds with qt5. And I have a local kcmshell5 kmdevice. As the
 other KCM modules are very thin it is not much work to complete.

All kmdevices, kminfo and kmsettings are ported to KF5 in the frameworks
branch:
http://quickgit.kde.org/?p=kolor-manager.gita=logh=7c50d0c6d2299ebdb04a0e883248f6169e93b87e

Now Oyranos should be read for Plasma 5.


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Oyranos-devel mailing list
Oyranos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oyranos-devel

Re: [Oyranos-devel] Fwd: gitorious.org close

[Kai-Uwe Behrmann]

My commits for Synnefo are now in github available:
https://github.com/oyranos-cms/Synnefo

They include a OS X framework, Qt5 support, cmake, documentation and 
some more changes.

kind regards
Kai-Uwe

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Oyranos-devel mailing list
Oyranos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oyranos-devel

Re: [Openexr-devel] OpenEXR files with nonlinearly encoded RGB

[Kai-Uwe Behrmann]

Am 27.02.2015 um 15:44 schrieb Elle Stone:
 On 02/23/2015 02:42 PM, Kai-Uwe Behrmann wrote:
 LCMS is just one CMM, with its prefered set of min and maximal values
 for certain colour spaces. I could never find it convincing to have
 CIE*L expressed in % in LCMS, the same goes for Cmyk - a printing space.
 But LCMS uses these fixed value ranges from inbuild defaults.

 I'm not sure what you mean by fixed value ranges from inbuild defaults.

 Since LCMS version 2 there is no clipping during conversions from RGB
 to LAB, XYZ, or another RGB color space. There's also no clipping upon
 export as long as the file format can hold 32-bit floating point RGB
 values outside the range 0-1 floating point.

Oh, I wrote from remembering lcms1, which is not much used these days.
You are right that the default value range changed with lcms2 to 0-1 for
floating point, which appears good to me.

 Of course there are precision limitations on how high those 32-bit
 floating point tiff values can go before there's too little precision
 for useful image editing, though I don't know where the line should be
 drawn.

Wikipedias Logluv_TIFF article links to the following:
http://www.anyhere.com/gward/hdrenc/hdr_encodings.html

 Are there differences in the number of stops that can be held in
 32-bit floating point tiffs vs 32-bit floating point OpenEXR images?


___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel

Re: [Lcms-user] API request

[Kai-Uwe Behrmann]

Am 25.02.2015 um 23:55 schrieb jcup...@gmail.com:
 On 25 February 2015 at 21:42, Richard Hughes hughsi...@gmail.com wrote:
 On 25 February 2015 at 21:09, Elle Stone ellest...@ninedegreesbelow.com 
 wrote:
 It would be nice to have a function that returns the library version at
 runtime (not just a header define). The reason is to prevent certain dll
 problems with Windows, by checking that the actually used library is the
 right one.
 Yes, this would be awesome for colord too; I'm happy to help with a
 patch if required.
 Another yes from me.

+1 (would help in Oyranos' lcm2 module to load the right functions from
liblcms)

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Openexr-devel] OpenEXR files with nonlinearly encoded RGB

[Kai-Uwe Behrmann]

Am 23.02.15 um 18:46 schrieb Elle Stone:
 On 02/23/2015 12:08 PM, Bob Friesenhahn wrote:
 However, floating point TIFF and ICC do not normally go hand in hand.

 I'm confused by this statement. LCMS reads and writes ICC profiles
 embedded in floating point tiffs. GIMP 2.9 exports 32f tiffs with
 embedded ICC profiles and darktable recognizes the embedded ICC
 profiles, and vice versa. And so on. And so forth.


LCMS is just one CMM, with its prefered set of min and maximal values
for certain colour spaces. I could never find it convincing to have
CIE*L expressed in % in LCMS, the same goes for Cmyk - a printing space.
But LCMS uses these fixed value ranges from inbuild defaults. IMO, it
would make much more sense to set colour space ranges per image and not
hard coded. So, yes the Tiff spec is mostly silent about floating point
data. Thus the implementation is at the discretion of each developer.
Only one pice of information comes to mind. Greg Ward introduced at one
point the nits tag.

How are value ranges handled inside OpenEXR supporting applications? Are
there conventions. Composing a candle light scene and a sun illuminated
scene into one image appears not straight forward - maybe.


___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel

Re: [PATCH 2/6] Attach input profiles and build corresponding LUTs

[Kai-Uwe Behrmann]

Am 27.11.2014 um 15:58 schrieb Niels Ole Salscheider:
  #define WL_HIDE_DEPRECATED
  #include wayland-server.h

 @@ -40,6 +41,10 @@ extern C {

  #include config-parser.h
  #include zalloc.h

 +#ifdef HAVE_LCMS
 +#include lcms2.h
 +#endif
 +

  #ifndef MIN
  #define MIN(x,y) (((x)  (y)) ? (x) : (y))
  #endif

 @@ -179,6 +184,24 @@ enum weston_mode_switch_op {

   WESTON_MODE_SWITCH_RESTORE_NATIVE
  
  };

 +struct weston_clut {
 + unsigned points;
 + char *data;
 +};
 +
 +struct weston_colorspace {
 +#ifdef HAVE_LCMS
 + cmsHPROFILE lcms_handle;
 +#endif
 + struct weston_clut clut;
 +
 + int destroyable;
 + int refcount;
 + int input;
 +
 + struct weston_compositor *compositor;
 +};
 Note, that compositor.h is a public, installed header. You cannot use
 HAVE_LCMS, because any external project using this header would then
 receive the definition based on its own configuration, not how the
 Weston that is already installed was configured.

Agreed, lcms internals are not nice to get exposed at this level.


Generally speaking, lcms provides a great API for a CMM. On the other
side, lcms is just one CMM and people in the open source world decided
many times to define and implement different API's. E.g. ArgyllCMS
(features, speed), SampleICC (spec playground) and Mozilla/Chrome with
qcms (secuirity, speed). So it is not wise to stick to especially one
CMM, be it lcms or whatever.

A CMM module can register its own functions for their handle type. You
could either wrap the CMM functions or use initial dummy functions
instead for function pointers. The type of the handle is not really
needed to get exposed. As long as the CMM registers its API at startup,
that procedure is simple.

A different approach is to store the data blob of the profile. The lcms
expanded profile handle needs certainly more memory, than the plain
memory block. And loading the profile on the fly is really fast. You
need the CMM profile handle mostly in the weston_build_clut() function
and for the header ID computation in other places. So profile memory
blob and profile header ID would suffice?

Then following might work out for the later approach:

+struct weston_colorspace {
+
+   void * profile_data;
+   int profile_data_size;
+   unsigned char profile_id[16];
+
+   struct weston_clut clut;
+
+   int destroyable;
+   int refcount;
+   int input;
+
+   struct weston_compositor *compositor;
+};


This opens the path to exchange the CMM without much fuzz on start time
depending on the system requirements.

Thanks
Kai-Uwe

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [Oyranos-devel] KF5

[Kai-Uwe Behrmann]

Am 26.11.2014 um 10:44 schrieb Casian Andrei:
 2014-11-26 11:33 GMT+02:00 Kai-Uwe Behrmann k...@gmx.de:

 Did you have a chance to check with Oyranos´ image-display application?
 No, I did not know about it. How is it launched?
 Is it installed when installing Oyranos?

It resides in build/src/examples/image-display and is not installed.
image-display can read ppm, png and cameraRAW files. With the oiio
plug-in as well jpeg and tiff.

The UI is too simple for general installation - no File open ... etc.
I have here a simple link to it. I attach my desktop file as it my be
useful.


image-display.desktop
Description: application/desktop
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Oyranos-devel mailing list
Oyranos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oyranos-devel

[Oyranos-devel] KF5

[Kai-Uwe Behrmann]

Hello Casian,

As kolor-manager:master relies now on libSynnefo, do we need to port
that to Qt5 before?

At least I will try to cherry pick today in order to get kded to the
same level as master.

kind regards
Kai-Uwe

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
Oyranos-devel mailing list
Oyranos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oyranos-devel

Re: [RFC PATCH v2 0/6] Initial per-surface color management

[Kai-Uwe Behrmann]

Am 29.10.2014 um 20:15 schrieb Niels Ole Salscheider:
 On Tuesday 28 October 2014, 15:45:18, Kai-Uwe Behrmann wrote:
 Am 27.10.2014 um 19:07 schrieb Niels Ole Salscheider:
 The support to mask the area of a surface so that its color space is not
 converted has been removed. Instead, the color profile of the main output
 of that surface can be attached if an application has a need to display
 uncorrected colors.
 I had a discussion regarding this with Zoxc on the IRC channel. Does it
 make sense to have a surface that is displayed uncorrected on multiple
 outputs with different output profiles?
 If so then this is not enough to detect that no color conversion should be
 applied at all.
 For measuring the colorimetric performance of outputs, for testing and
 scalability, it appears the easiest to have a colormanagement-off
 switch. On osX, without such switch, the mechanism to attach the monitor
 profile to the input image brings headache to developers and this
 workaround does not work reliably.
 Sure, I introduced the possibility to disable color correction of a surface 
 for these use-cases in my first proposal.
 But is it really enough to just not apply color corrections to a surface? Or 
 would this use-case require to deactivate color correction completely, as 
 argued by John Kåre Alsaker?

I can only guess what the motivation for a per output switch-off might be:
* graphic cards video lut handling
* compositing space triggering
* consistency with alpha blending behaviour for stacked transparent
surfaces with and without CM enabled
* effects on top of windows (sepia, etc.)

Some of the above mentioned mechanisms are not easy to integrate. So the
best is to have access to each mechanism by an separate API and let
applications handle them on need.

For compositing might arise the need to switch off the compositing
space. So a transparent widget on top of a graphics application will not
make the case to touch the rgb numbers, except for the blending areas of
course. Further the transparent widget can overlap in parts the CM-off
widget and normal areas at the same time. So the compositing of the
different areas has to be handled separately. Given that for different
outputs different colour conversions are needed, that feature appears
not that far stretched. The user experience will be relatively smooth.

In contrary, a global CM-off will have many side effects, which make
potentially a unwanted user experience for Yuv video, or other widgets,
which should not be affected on desktops. On handheld systems, that is
less of concern.

 In the latter case, it might be better to add another protocol that allows 
 such tools to temporarily deactivate any color conversions...

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC PATCH v2 0/6] Initial per-surface color management

[Kai-Uwe Behrmann]

Am 27.10.2014 um 19:07 schrieb Niels Ole Salscheider:
 The support to mask the area of a surface so that its color space is not
 converted has been removed. Instead, the color profile of the main output
 of that surface can be attached if an application has a need to display
 uncorrected colors.
 I had a discussion regarding this with Zoxc on the IRC channel. Does it make 
 sense to have a surface that is displayed uncorrected on multiple outputs 
 with 
 different output profiles?
 If so then this is not enough to detect that no color conversion should be 
 applied at all.

For measuring the colorimetric performance of outputs, for testing and
scalability, it appears the easiest to have a colormanagement-off
switch. On osX, without such switch, the mechanism to attach the monitor
profile to the input image brings headache to developers and this
workaround does not work reliably.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [Lcms-user] free fallback CMYK profile

[Kai-Uwe Behrmann]

On  the OpenICC wiki are popular freely distributable and non free profile 
packages listed:
http://www.freedesktop.org/wiki/OpenIcc/ProfilePackages/

kind regards
Kai-Uwe

On 22. August 2014 10:57:33 MESZ, jcup...@gmail.com wrote:
Can anyone point me to a reasonable, freely-licenced CMYK profile?
-- 
Kai-Uwe Behrmann
www.behrmann.name

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] ddc/ci and color management

[Kai-Uwe Behrmann]

Am 18.05.2014 16:24, schrieb Sanford Rockowitz:
 When I perform a calibration, it's specific to the current settings of 
 the monitor: color temperature, RGB channel settings, brightness, etc. 
 Yet handling these settings is an out of band process.  It's the user's 
 responsibility to manually adjust the monitor settings and record the 
 values before calibration, and restore them manually if necessary.  At 
 the very least, it would be desirable to record those settings in the 
 profile, or even just have a utility that allowed me to record the 
 settings and possibly restore them.

 All this should be possible with DDC/CI, but DDC/CI doesn't seem to be 
 supported on Linux.   There's ddccontrol, but it doesn't appear to have 
 been updated in years.   When I try to run it, it doesn't recognize my 
 monitors or complains that the data returned is invalid.   I've tried 
 using i2cdump.  I can read the EDID data at address 0x50.  My 
 understanding is that the DDC data is at address 0x30, but when I read 
 from that address I get nothing.  xcmddc can identify the i2c buses for 
 monitors, but that's about it.  The comments in XcmDDC suggest that much 
 greater capabilities were intended.

 Googling, I find a bunch of posts from Kae-Uwe Berman, Graeme Gill, 
 Richard Hughes and others circa 2009-2010  (e.g. 
 http://comments.gmane.org/gmane.comp.freedesktop.xorg/41559, 
 http://lists.x.org/archives/xorg-devel/2010-July/010922.html) Then 
 discussion of this topic seems to die.

 All this leads me to think that there's something fundamentally 
 problematic about using DDC/CI in Linux.   Is that the case, or is there 
 a solution that I've overlooked?  If no general solution is possible, is 
 there at least a path for me to cobble together something that works for 
 my specific monitors and systems?

xcmddc's intention was to make information available for automation of
monitor settings to initially profiling software and colour management
systems. I just did not had enough time to figure ddc/ci out.  The EDID
code is available in several stacks.

DDC/CI in Linux needs attention of a developer. That's perhaps all needed.

kind regards
Kai-Uwe

--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] PNG support

[Kai-Uwe Behrmann]

Am 16.05.2014 16:04, schrieb Szczepan Czaicki:
 I'm searching for library capable of converting color profiles in PNG
 images. I tried to search on website, on mailing group archives, on
 tutorials if littleCMS supports them, but I can't find any information
 saying anything about PNG images. I installed lcms2 using cygwin package
 manager but I only have such scripts:
 - jpgicc,
 - linkicc,
 - psicc,
 - tificc,
 - transicc,
 So my question is, can I use somehow littleCMS to convert PNG image to
 different colorprofile?

Try oyranos-icc, part of the Oyranos CMS. It uses by default lcms2.

--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] Bug? conversion value discrepencies if the destination profile is built-in vs on disk

[Kai-Uwe Behrmann]

Am 07.04.2014 18:17, schrieb Elle Stone:
 Different results obtain from converting to a built-in profile in memory 
 vs the same profile save to disk.

 Is it accurate to say that the results are different because the added 
 precision in the profile in memory means the profile in memory really 
 isn't the same profile.

ICC profiles may contain a hash value sometimes called a ID. That is
computed out of nearly all content of the profile including all
colorimetric tags. In order to create a profile precisely representing
your above mentioned lcms build-in, in memory profiles, different tag
types would be needed to represent the higher precission. That would in
effect mean that the ID of such profile would be different than what can
now be written to disk. Hence the profiles are different by that definition.

Caching of profiles and transforms depend on the ID in order to work
relyable. So there is prectical use in this information.

 A consequence of this situation is that pure white in the image on disk 
 will become slightly off white after being converted to the built-in 
 profile, even if the embedded profile and the built-in profile are 
 nominally the same, because really they aren't the same:

 transicc -w -c0 -b -t1 -i sRGB-lcms-built-in.icc -o *sRGB
 R? G? B? 255 255 255
 R=254.9988 G=255.0029 B=254.9981

Correct round tripping was at some point an argument to implement non
ICC colour matching engines. So I guess your point is spot on for some
users.

 If one wants to preserve white when converting from the profile on disk 
 to the same profile in memory, is there a way to tell the built-in 
 profile in memory to *not* use the extra precision?

As a side note, correct round tripping became possible with the
introduction of the mpet tag type. However mpet tags are only optional
substitutes for A2Bx and B2Ax tags. So they can not be used for matrix
shaper profiles. The later are the ones written by lcms for the build-in
profiles you examined.

If matrix shaper profiles could use a XYZ tag type with floating point
precission your issue would be gone.

kind regards
Kai-Uwe
-- 
www.behrmann.name

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: Wayland Live CD now switching to Mir

[Kai-Uwe Behrmann]

Am 01.04.2014 14:40, schrieb nerdopolis:
 As you all know, I have been the developer of the Wayland live CD for some 
 time, which is named after my favorite celebrity, and has been providing a 
 easy to obtain Wayland environment for users since 2012.
  
 However I have been recently looking at the Wiki pages for Mir, and I am 
 realizing that the Wiki pages have much nicer looking flowcharts then 
 Wayland's wiki, and now I have decided to switch it over to Mir.

Which wiki do you mean?

wikipedia?:
https://en.wikipedia.org/wiki/Mir_%28display_server%29
https://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29

kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC PATCH 1/6] Add colorcorrection protocol

[Kai-Uwe Behrmann]

Am 31.03.2014 09:46, schrieb Pekka Paalanen:
 On Sun, 30 Mar 2014 13:36:32 +0200
 Niels Ole Salscheider niels_...@salscheider-online.de wrote:

 The color correction protocol allows to attach an ICC profile to a
 surface. It also tells the client about the blending color space and
 the color spaces of all outputs.

 Signed-off-by: Niels Ole Salscheider niels_...@salscheider-online.de
 ---
  Makefile.am  | 15 ++--
  protocol/colorcorrection.xml | 87 
 
  2 files changed, 98 insertions(+), 4 deletions(-)
  create mode 100644 protocol/colorcorrection.xml

 diff --git a/Makefile.am b/Makefile.am
 index 5ff4f83..ec0a30b 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -76,7 +76,9 @@ nodist_weston_SOURCES =
 \
  protocol/workspaces-protocol.c  \
  protocol/workspaces-server-protocol.h   \
  protocol/scaler-protocol.c  \
 -protocol/scaler-server-protocol.h
 +protocol/scaler-server-protocol.h   \
 +protocol/colorcorrection-protocol.c \
 +protocol/colorcorrection-server-protocol.h
  
  BUILT_SOURCES += $(nodist_weston_SOURCES)
  
 @@ -426,7 +428,9 @@ nodist_libtoytoolkit_la_SOURCES =
 \
  protocol/workspaces-protocol.c  \
  protocol/workspaces-client-protocol.h   \
  protocol/xdg-shell-protocol.c   \
 -protocol/xdg-shell-client-protocol.h
 +protocol/xdg-shell-client-protocol.h\
 +protocol/colorcorrection-protocol.c \
 +protocol/colorcorrection-client-protocol.h
  
  BUILT_SOURCES += $(nodist_libtoytoolkit_la_SOURCES)
  
 @@ -606,7 +610,9 @@ BUILT_SOURCES += \
  protocol/workspaces-client-protocol.h   \
  protocol/workspaces-protocol.c  \
  protocol/xdg-shell-protocol.c   \
 -protocol/xdg-shell-client-protocol.h
 +protocol/xdg-shell-client-protocol.h\
 +protocol/colorcorrection-protocol.c \
 +protocol/colorcorrection-client-protocol.h
  
  
  westondatadir = $(datadir)/weston
 @@ -920,7 +926,8 @@ EXTRA_DIST +=\
  protocol/text-cursor-position.xml   \
  protocol/wayland-test.xml   \
  protocol/xdg-shell.xml  \
 -protocol/scaler.xml
 +protocol/scaler.xml \
 +protocol/colorcorrection.xml
  
  man_MANS = weston.1 weston.ini.5
  
 diff --git a/protocol/colorcorrection.xml b/protocol/colorcorrection.xml
 new file mode 100644
 index 000..7986e93
 --- /dev/null
 +++ b/protocol/colorcorrection.xml
 @@ -0,0 +1,87 @@
 +?xml version=1.0 encoding=UTF-8?
 +protocol name=colorcorrection
 +
 +  copyright
 +Copyright © 2014 Niels Ole Salscheider
 +
 +Permission to use, copy, modify, distribute, and sell this
 +software and its documentation for any purpose is hereby granted
 +without fee, provided that the above copyright notice appear in
 +all copies and that both that copyright notice and this permission
 +notice appear in supporting documentation, and that the name of
 +the copyright holders not be used in advertising or publicity
 +pertaining to distribution of the software without specific,
 +written prior permission.  The copyright holders make no
 +representations about the suitability of this software for any
 +purpose.  It is provided as is without express or implied
 +warranty.
 +
 +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
 +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
 +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
 +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
 +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
 +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
 +THIS SOFTWARE.
 +  /copyright
 +
 +  interface name=wl_colorcorrection version=1
 +description summary=allows to attach a color profile to a wl_surface
 +  This interface allows to attach a color profile to a wl_surface.
 +  This is used by the compositor to display the colors correctly.
 +  The client is informed by two events about the blending space used
 +  by the compositor and the color spaces of the outputs.
 +/description
 +
 +request name=set_profile
 +  description summary=set the color profile of a wl_surface
 +With this request, the color profile of a wl_surface can be set.
 +When mode is set to profile, an ICC profile can be passed in the
 +profile_data argument. In all other cases, profile_data is
 +ignored.
 +mode should only be set to uncorrected for fullscreen applications
 +or applications that 

Re: [RFC PATCH 2/6] Attach input profiles and build corresponding LUTs

[Kai-Uwe Behrmann]

Am 30.03.2014 13:36, schrieb Niels Ole Salscheider:
 This implements the functionality to attach a profile to a surface
 in weston. An LUT is built from the profile that can be used to
 transform colors from the input color space to the blending color
 space.
 This patch uses the sRGB color space as blending space because it
 uses 8 bit LUTs for now and I want to avoid additional banding. In
 the long term we should use a linear blending space though to get
 correct results.

Banding will be serious with a pure linear gamma in 8-bit encoded
3D-LUT. pre- and post per channel processing can help to reduce the
artefacts.

kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC PATCH 1/6] Add colorcorrection protocol

[Kai-Uwe Behrmann]

Am 31.03.2014 11:43, schrieb Pekka Paalanen:
 On Mon, 31 Mar 2014 09:25:34 +0100
 Richard Hughes hughsi...@gmail.com wrote:

 On 31 March 2014 08:46, Pekka Paalanen ppaala...@gmail.com wrote:
 how much data can an ICC profile be?
 Printer profiles can be several megabytes in size, but display
 profiles (what will be seen here) are usually in the 20-30kb size
 range.
 I do wonder if we will have a problem with the maximum message
 size in Wayland. I'm not sure how the maximum is determined, and since
 profiles could in theory be very big, I'd propose using an out-of-band
 method for transferring that data.

 Also, what if a client has several surfaces all with the same ICC
 profile, would it not be useful to have some notion of re-using an
 already sent and parsed color profile? Otherwise I would imagine lots
 of overhead if every surface has a private copy of the profile
 sent over the wire, parsed, and stored in the compositor's renderer.
 I don't think typically they'll be many different profiles in use, on
 a typical system most things will just be (assumed) sRGB to 'n'
 display profiles, where n is the number of outputs.
 I take that as yes, explicit re-use would be very useful to avoid
 parsing, comparing and coalescing at every turn.

 Is that a reasonable requirement for all compositors that support
 per-output ICC profiles?
 I think it's a very little amount of work, IMO doing it centrally
 makes a lot of sense as some bits are tricky to do correctly.
 Tricky should be solve by shared libraries rather than a daemon,
 IMHO. I'm more concerned about the amount of work the compositor will
 be doing, not the work for implementing it. I think such color space
 conversion should be accounted for the client, i.e. done in the client.

The concerns of KWin's Martin where at time of implementing CM, that
colour conversions shall be done in one place. Pro inside KWin was
mentioned to have only few LUTs applied to many textures. In the logical
opposite, contra client side conversions was the need to compute store
and cache all LUTs per client, without much sharing among different
clients running under one compositor.

Feature wise, the only output aware colour correcting applications I
know of under Linux are two compositors, with Niels path three, and some
client side example code in Oyranos. So moving stuff to the clients will
very likely loose those valuable features like per output correction,
speedy ICC colour corrected movie displaying, consitency etc.

 It would be wasteful, if a compositor needs to compute the source
 conversion every time it just repaints the screen, even if the content
 for a color-managed surface has not changed. I'm assuming a compositor
 would be texturing directly out of a client's buffer.

In many cases a client is not remotely able to compute per output
regions without much information about scaling, positioning, (warping?)
etc. In the past very few clients used that informations even if
available. See my comment above. Client side colour correction (early
colour binding) was and is a corner case - even sometimes a very
valuable one. With more features going inside compositors, it becomes
for clients harder to predict on which output a pixel will appear.
Practical clients would need to analyse all effects a compositor
performs on a clients buffer, for that to work correctly.

 I would also like to have room for compositors that blend in a
 non-ideal color space. Having a separate blending color space is
 essentially an additional copy, AFAIU, which is a pretty high cost for
 something, whose result any single client cannot assume at all, anyway.
 I still think that if a client needs the result of blending non-opaque
 pixels to be guaranteed, it should do it itself and not rely on the
 server.

 Overall, I'm very happy to see someone pick up this work. Thanks.
 Indeed.

kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC PATCH 1/6] Add colorcorrection protocol

[Kai-Uwe Behrmann]

Am 31.03.2014 16:10, schrieb Pekka Paalanen:
 On Mon, 31 Mar 2014 11:29:03 +0200
 Kai-Uwe Behrmann ku.b-l...@gmx.de wrote:

 Am 31.03.2014 09:46, schrieb Pekka Paalanen:
 On Sun, 30 Mar 2014 13:36:32 +0200
 Niels Ole Salscheider niels_...@salscheider-online.de wrote:

 The color correction protocol allows to attach an ICC profile to a
 surface. It also tells the client about the blending color space and
 the color spaces of all outputs.

 Signed-off-by: Niels Ole Salscheider niels_...@salscheider-online.de
 ---
  Makefile.am  | 15 ++--
  protocol/colorcorrection.xml | 87 
 
  2 files changed, 98 insertions(+), 4 deletions(-)
  create mode 100644 protocol/colorcorrection.xml

 diff --git a/Makefile.am b/Makefile.am
 index 5ff4f83..ec0a30b 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -76,7 +76,9 @@ nodist_weston_SOURCES =  
 \
protocol/workspaces-protocol.c  \
protocol/workspaces-server-protocol.h   \
protocol/scaler-protocol.c  \
 -  protocol/scaler-server-protocol.h
 +  protocol/scaler-server-protocol.h   \
 +  protocol/colorcorrection-protocol.c \
 +  protocol/colorcorrection-server-protocol.h
  
  BUILT_SOURCES += $(nodist_weston_SOURCES)
  
 @@ -426,7 +428,9 @@ nodist_libtoytoolkit_la_SOURCES =  
 \
protocol/workspaces-protocol.c  \
protocol/workspaces-client-protocol.h   \
protocol/xdg-shell-protocol.c   \
 -  protocol/xdg-shell-client-protocol.h
 +  protocol/xdg-shell-client-protocol.h\
 +  protocol/colorcorrection-protocol.c \
 +  protocol/colorcorrection-client-protocol.h
  
  BUILT_SOURCES += $(nodist_libtoytoolkit_la_SOURCES)
  
 @@ -606,7 +610,9 @@ BUILT_SOURCES +=   
 \
protocol/workspaces-client-protocol.h   \
protocol/workspaces-protocol.c  \
protocol/xdg-shell-protocol.c   \
 -  protocol/xdg-shell-client-protocol.h
 +  protocol/xdg-shell-client-protocol.h\
 +  protocol/colorcorrection-protocol.c \
 +  protocol/colorcorrection-client-protocol.h
  
  
  westondatadir = $(datadir)/weston
 @@ -920,7 +926,8 @@ EXTRA_DIST +=  \
protocol/text-cursor-position.xml   \
protocol/wayland-test.xml   \
protocol/xdg-shell.xml  \
 -  protocol/scaler.xml
 +  protocol/scaler.xml \
 +  protocol/colorcorrection.xml
  
  man_MANS = weston.1 weston.ini.5
  
 diff --git a/protocol/colorcorrection.xml b/protocol/colorcorrection.xml
 new file mode 100644
 index 000..7986e93
 --- /dev/null
 +++ b/protocol/colorcorrection.xml
 @@ -0,0 +1,87 @@
 +?xml version=1.0 encoding=UTF-8?
 +protocol name=colorcorrection
 +
 +  copyright
 +Copyright © 2014 Niels Ole Salscheider
 +
 +Permission to use, copy, modify, distribute, and sell this
 +software and its documentation for any purpose is hereby granted
 +without fee, provided that the above copyright notice appear in
 +all copies and that both that copyright notice and this permission
 +notice appear in supporting documentation, and that the name of
 +the copyright holders not be used in advertising or publicity
 +pertaining to distribution of the software without specific,
 +written prior permission.  The copyright holders make no
 +representations about the suitability of this software for any
 +purpose.  It is provided as is without express or implied
 +warranty.
 +
 +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
 +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
 +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
 +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
 +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
 +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
 +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
 +THIS SOFTWARE.
 +  /copyright
 +
 +  interface name=wl_colorcorrection version=1
 +description summary=allows to attach a color profile to a 
 wl_surface
 +  This interface allows to attach a color profile to a wl_surface.
 +  This is used by the compositor to display the colors correctly.
 +  The client is informed by two events about the blending space used
 +  by the compositor and the color spaces of the outputs.
 +/description
 +
 +request name=set_profile
 +  description summary=set the color profile of a wl_surface
 +  With this request, the color profile of a wl_surface can be set.
 +  When mode is set to profile, an ICC profile can be passed in the
 +  profile_data argument. In all other cases, profile_data is
 +  ignored.
 +  mode should only be set

Re: [Lcms-user] Release candidate of lcms2-2.6 now available

[Kai-Uwe Behrmann]

Am 13.02.2014 23:05, schrieb Graeme Gill:
 marti.ma...@littlecms.com wrote:

 Yep, that is how actually works, and this is the source of all pain.
 What I really need is a sort function that given a pointer, would guess
 if this points to a cmsContext internal structure or to used supplied
 data.
 If the client code has to be changed anyway to use the new cmsContext
 (ie. to get one and then supply it to each function call), then another
 approach would be to use different function names for the cmsContext,
 ie. cmsCreate_sRGBProfileLCX() etc., so that the _THR functions
 can remain unchanged, and internally there is then no doubt
 about what sort of context it is.

1+
Escaping the incompatible APIs appears to me as the best suggestion so
far. _THR functions can be deprecated and a new function set can be
introduced at the same release. THR would be removed on the next major.
The changes on user side would not involve more work on making them
ready for the new APIs. But it would satisfy old code demands, which
makes sense to many users.

kind regards
Kai-Uwe

--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] Release candidate of lcms2-2.6 now available

[Kai-Uwe Behrmann]

Am 13.02.2014 17:51, schrieb marti.ma...@littlecms.com:
 Still, the issue continues to be in how to differentiate cmsContext
 from user data. If we could fix that, then compatibility would
 be kept.

Just an idea:

typedef struct {
  const char type_[8];
  // more members here
  void * user_data;
} cmsContext;

cmsContext c = {lcms2.6, NULL};

cmsContext * cmsTakeContext( cmsStruct ptr )
{
  cmsContext * c = ptr-context;
  if(sizeof(*c)  8  memcmp(c-type_, lcms2.6, 8) == 0)
return c-user_data;
  else
return c;
}

The above example comes with some computational cost. But you can skip
this check with lcms-3.0 in the future.

Alternatively a enum might be fine too. Obviously there remains a risk
that a four byte type identifier might fit by accident to the four bytes
enum, and thus above function returns a wrong pointer.

kind regards
Kai-Uwe

--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] How to specify *nix as the platform

[Kai-Uwe Behrmann]

Am 25.01.2014 01:41, schrieb marti.ma...@littlecms.com:
 Elle, the problem is *nix is not a registered signature and therefore  
 you would produce non-conformant profiles if using that. The icc  
 profile dump app issues a warning, and I know about more than one  
 company using that tool to validate profiles. Otherwise, a CMM should  
 *not* make any distinction from this fieldso, its usage is purely  
 testimonial.

 Actually lcms uses it as a watermark and only mac and windows are  
 supported. It is like the creation date: is supposed to be put there  
 by the system and nobody should use it.

The testimonial header fields are used to generate statistics from e.g.
the Taxi DB on http://icc.opensuse.org . Without that some interessting
informations about OS collaboration and timelines would be non accessible.

kind regards, Kai-Uwe



--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Development] Qt Color Profiles update

[Kai-Uwe Behrmann]

I can not see much changes on codereview from your link since summer of
last year. What do I miss?

Your attached PDF was interessting, thanks for it.

kind regards
Kai-Uwe Behrmann

Am 16.12.2013 10:43, schrieb Alexandros Dermenakis:
 Hello!

 I am working on merging a patch I made in summer 2012 on Color
 Profiles for Qt 5. There are several small issues to be solved but it
 seems that it won't take too long.

 The link to the related patches is :
 https://codereview.qt-project.org/#dashboard,1002033

 The functionality allows converting the color profiles on QImages

 More details on gerrit :

 I am also sending my thesis report which was on adding support for
 color profiles on embedded systems. You can go through it to get ideas
 about implementation and research background.

 I am also sending some sample code along with shaders (GLES 2) for
 performing color conversion. I have testing the code on the Nokia N9
 and the only dependencies are GLES2 and LittleCMS2 (with some small
 modifications) which are included in the sample code.


 Best,
 -- 
 Alexandros Dermenakis
 *B.Eng *Software Engineering
 *Email:* alexandros.dermena...@gmail.com
 mailto:alexandros.dermena...@gmail.com
 *Mobile:* +32 (0) 49 143 - 8890
 tel:%2B32%20%280%29%2049%20143%20-%208890
 *Website:* www.alexandrosdermenakis.com
 http://www.alexandrosdermenakis.com

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Color Management support in Qt 5?

[Kai-Uwe Behrmann]

Am 10.11.2013 11:05, schrieb John Layt:
 On 9 November 2013 12:50, Olivier Goffart oliv...@woboq.com wrote:
 On Saturday 09 November 2013 03:02:18 Alessandro Portale wrote:
 I like the idea of re-starting small, and quite a bit of what was done
 in Nokia times can certainly be re-used.
 What if Qt started by simply *enabling* color management. I.e. giving
 access to the information that an application needs to perform color
 management tasks itself. In a much later iteration Qt could perhaps
 perform color management operations. Qt should IMHO avoid automatic
 color management under the hood, especially without providing API to
 control it.

 Milestones could be:
 1) QImage[Reader] gives access to image color profile. Either whole
 profile or just an identifier in case of standard spaces such as sRgb.
 2) QScreen gives access to the current display color profile for that
 specific screen.
 3) There are notifications (signals?) when the a window changes to
 another screen, or when a screen profile is changed in the system.
 4) Same as 2 but for installed Printers on the system.
 ...
 99) QColorEngine can do color conversions using an input profile, a
 source Image an output profile plus different parameters.

 Ideas? Kai-Uwe, what color management feature (or enabler) are you
 missing most in Qt?
 Allow me to disagree :-)
 How usefull are 1-4 without 99?  What exactly can you do with that
 information.
 Well, I'm no expert at the graphics side of things, but I think before
 you can start applying a color profile you need to know what color
 profile to apply :-)  If we at least expose that config for apps to
 use then they only need to apply the transforms themselves, rather
 than also having to abstract the system config.  Then afterwards we
 can start using the config ourselves in our own code.  OTOH we don't
 want to ship api that we may have to change later when we start using
 it ourselves in anger.

 I think step 1 is very definitely a cross-platform api to access the
 host system config and profiles, regardless of whether we make it
 public or not.  That's easy enough for Windows and Mac where each has
 a single color management framework built-in, but on Linux we still
 have two competing systems (perhaps Kai-Uwe can update us on that
 situation, is there a single combined config yet?).

Most applications use for Xorg the ICC Profile in X spec [1]. The spec 
is served by Oyranos CMS as well as the colord CMS and others.

 Now, to really expose my lack of knowledge, AFAIK Mac especially and
 Windows graphics contexts can apply the required transforms themselves
 internally, so wherever we use the native context it's surely just a
 case of configuring them to do the work for us?  It's really only on
 Linux or XP that we would have to have code for doing the transforms
 ourselves using LCMS?  But like I said, I know nothing of our graphics
 internals :-)

Lcms is for realtime conversions too slow. OpenGL provides in some 
profiles a 3D texture lookup on the GPU, which is fast.

kind regards
Kai-Uwe Behrmann

[1] 
http://www.openicc.info/index.php?title=ICC_Profiles_in_X_Specification_0.4
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Color Management support in Qt 5?

[Kai-Uwe Behrmann]

Am 09.11.2013 12:50, schrieb Olivier Goffart:
 On Saturday 09 November 2013 03:02:18 Alessandro Portale wrote:
 Allow me jump into this topic to contribute to its liveliness :)

 The term Color Management has been used in different ways here on
 the list. Lately, it was about how to blend images in a non-linear
 color space. That is IMHO perhaps a small and not that typical part
 of what color management means for imaging applications.

 I like the idea of re-starting small, and quite a bit of what was done
 in Nokia times can certainly be re-used.
 What if Qt started by simply *enabling* color management. I.e. giving
 access to the information that an application needs to perform color
 management tasks itself. In a much later iteration Qt could perhaps
 perform color management operations. Qt should IMHO avoid automatic
 color management under the hood, especially without providing API to
 control it.

 Milestones could be:
 1) QImage[Reader] gives access to image color profile. Either whole
 profile or just an identifier in case of standard spaces such as sRgb.
 2) QScreen gives access to the current display color profile for that
 specific screen.
 3) There are notifications (signals?) when the a window changes to
 another screen, or when a screen profile is changed in the system.
 4) Same as 2 but for installed Printers on the system.
 ...
 99) QColorEngine can do color conversions using an input profile, a
 source Image an output profile plus different parameters.

 Ideas? Kai-Uwe, what color management feature (or enabler) are you
 missing most in Qt?
 Allow me to disagree :-)
 How usefull are 1-4 without 99?  What exactly can you do with that
 information.

 All the QPainter API assume linear colorspace (at least in the raster paint
 engine). And that would be difficult to change that and the result would be 
 much
 slower painting.
 What does the scene graph do?

 That means that when you blend images or smooth scale, or antialias, Qt assume
 everything is in the linear colorspace.

 I think milestones could rather be:

 1) QImage[Reader] converts automatically to linear color space, so that all
 QImage's are in the linear color space
 2) A conversion to the screen's colorspace is done at the end (by the
 platform plugin?  by the compositor?)
 3) Allow QImage to be in any colorspace and have QImage::colorProfile()
 4) change QPainter, and graphicssystem to handle different colorspaces.

Alessandros feature list allows for early binding by applications. That 
is essentially what colour managed apps do today. They take input 
colours and convert them to output colours themself. With the mentioned 
APIs inside Qt, they can do that the Qt way without platform specific code.

Oliver,
what you describe is about late colour binding.
A minor annotation to your point 1)
  QImage[Reader] converts automatically to linear color space, so that 
all QImage's are in the linear color space
Some app authors will dislike to be forced to have uncontrolled colour 
conversions. So I would like to add the feature request for a conversion 
switch off for opaque images. Uncontrolable changes of pixel colours can 
result in e.g. wrong measurements for ICC profile generation.

Otherwise I do not see a contradiction to what Alessandro wrote as his 
feature list is a precondition to do the automatic or late colour 
binding stuff.

kind regards
Kai-Uwe Behrmann
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Color Management support in Qt 5?

[Kai-Uwe Behrmann]

Am 08.11.2013 14:17, schrieb Sorvig Morten:
 
 On 07 Nov 2013, at 12:48, Kai-Uwe Behrmann k...@gmx.de wrote:
 
 Detecting a colour space and converting to device colour spaces is around 
 the same amount of developer time as for special casing sRGB. Detecting sRGB 
 among hundrets of ICC profiles is not trivial or fast, while such a 
 detection does not matter in a generic colour managed environment.

 EXT_texture_sRGB provides only sRGB gamma to linear gamma conversions. That 
 is a thiny bit of grafic processing, which is needed for handling colour 
 space conversions. 
 The spec is clear to not doing anything about dislpaying sRGB images on a 
 monitor. So this OpenGL extension does not help much with colour management.

 Short term support for sRGB only would make Qt a pretty limiting choice for 
 many colour managed applications.

 IMHO, limiting support to RGB in a first development stage is a more sound 
 target.
 
 
 Hello! 
 
 You did not give me much wiggle room with this reply - did you simply want to 
 end the discussion?

Oh, I joined the discussion to keep it alive. Sorry, if my reply was
perceived in a different mode.

 For example, the existance of EXT_framebuffer_sRGB supports my argument that 
 limiting support to sRGB will be simpler, but you don’t mention it at all.

As I mentioned, the GL extension does no complete colour space
conversion as it handles only gamma and not colour primaries. It is
intented for memory storage savings, which are unrelated to any colour
management concerns. In fact a small shader can do a similar gamma
correction. On the other hand a different shader could do as well a full
colour space conversion. sRGB is other than for storage not of much value.

Nonetheless sRGB is traditionally used as factual blending space. But
e.g. wayland devs think seriously around linear gamma blending spaces,
which give lesser artefacts.

If one plans for mobile only, then a single blending colour space with
low bit depth storage might be an option. But I wanted to point out,
that this appears to me like a serious regression on desktop. The
implications are certainly up to decide by the Qt community.

kind regards
Kai-Uwe Behrmann
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Color Management support in Qt 5?

[Kai-Uwe Behrmann]

Detecting a colour space and converting to device colour spaces is around the 
same amount of developer time as for special casing sRGB. Detecting sRGB among 
hundrets of ICC profiles is not trivial or fast, while such a detection does 
not matter in a generic colour managed environment.

EXT_texture_sRGB provides only sRGB gamma to linear gamma conversions. That is 
a thiny bit of grafic processing, which is needed for handling colour space 
conversions.
The spec is clear to not doing anything about dislpaying sRGB images on a 
monitor. So this OpenGL extension does not help much with colour management.

Short term support for sRGB only would make Qt a pretty limiting choice for 
many colour managed applications.

IMHO, limiting support to RGB in a first development stage is a more sound 
target.

kind regards
Kai-Uwe Behrmann




Sorvig Morten morten.sor...@digia.com schrieb:

On 06 Nov 2013, at 17:18, Kai-Uwe Behrmann k...@gmx.de wrote:

 What is the point of special casing sRGB?

sRGB is special for a couple of reasons:
- Most/Many of the images published for web are in the sRGB color space.
- OpenGL has support for sRGB textures and frame buffers.

Given that progress has halted on this so far it might be good idea to reduce 
scope to something that can be completed cross-platform in a reasonable amount 
time.

There are arguments against as well, we don’t want to add API that would limit 
(future) support to sRGB only for example.

Morten






_

Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Color Management support in Qt 5?

[Kai-Uwe Behrmann]

What is the point of special casing sRGB?

kind regards
Kai-Uwe Behrmann




Sorvig Morten morten.sor...@digia.com schrieb:


On 04 Nov 2013, at 10:49, John Layt jl...@kde.org wrote:

 On 4 November 2013 08:22, Sletta Gunnar gunnar.sle...@digia.com wrote:
 The work that was done is here: 
 https://codereview.qt-project.org/#dashboard,1002033

 The work was abandoned after the transition to Digia and the author is no 
 longer in the Qt community, so little has happened since then.

 Thanks. It's a question that pops up in KDE every now and then, and
 for printing too, so just thought I'd check. We'll have to continue
 to work around it for now, but I'll try find if anyone in the color
 management community wants to take on the task.

I believe the most urgent issue is handling sRGB images correctly. Perhaps we 
can start there and sketch out some possible solutions?

Morten


_

Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [GSoC] Color management support in Wayland

[Kai-Uwe Behrmann]

Hello Rafael,

Am 17.06.2013 17:28, schrieb Rafael Fonseca:

I'll be working on porting the color management done in Gnome (and X)
to Wayland. I'm still on the studying and understanding the problem


Will Gnome rely on Weston as it's compositor? In other words, will your 
changes become available to Weston?



phase, but I already know that it'll be needed to create support for
cube transformation for each color profile.


For CM in the compositor that is indeed needed. For per monitor colour 
correction the per input profile transforms are to be multiplied by the 
number of monitors / outputs with distinct profiles.


kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Wayland color management protocol proposal

[Kai-Uwe Behrmann]

(taking Richard out of CC as he replied on list)

Am 19.06.2013 04:52, schrieb John Kåre Alsaker:

Here is my current color management protocol for Wayland clients. The
basic idea is that the compositor sends two color spaces to the
clients. A compositing color space which the compositor prefers since
it would require no conversions. A full-screen color space which the
compositor can be able to scan out from. The full-screen color space
is intended to used by games which are able to do color conversions as
part of their post-processing. It's also possible it could be used by
video players.


Just rewording to get all in sync about the terms.
The compositor colour space appears like a kind of document colour 
space, which the desktop/display is in. In the existing colour managed 
compositors that defaults to sRGB, but can of course be a different 
space like you suggest here.


The full-screen color space reads like the main outputs device space. 
Is that notation correct?


For various clients it would be essential to see each outputs native 
space as well. Multi monitor aware colour correction in some essential 
for artists applications as well as analysing software come to mind.



Different rendering intents and more advanced color spaces have not
explicitly been considered here, but I hope the use of ICC profiles
will cover these.


From a architecture point of view, that is not so easy. There are few 
CMS'es around to modify the rendering bits in a ICC profile. Secondly as 
the profiles are passed by file name, that would require copying before 
giving to Wayland, which sounds unfortunate and might cause confusion 
later on.



Calibration tools will require explicit privileges in order to do
their job. Using the full-screen color space won't be enough since
video card gamma correction can apply to it. I also wonder if we can
just remove the VCGT tag from the ICC profiles to indicate that the
client doesn't have to correct for that, but I'm not sure that anyone
would use the tag anyway.


Sending a faked no VCGT profile is slightly indirect, but might work 
out. That needs to be documented very well. A calibration/profiling 
program needs then to set the VCGT-less profile to the output in 
question and then displays its measurement patches on a surface without 
colour conversion.


To deprecate the VCGT tag is not so easy, as we have lots of legacy 
profiles around from windows / osx software and directly from vendors. 
Ignoring the VCGT tag is no option, modifying the profile by baking the 
VCGT tag into the ICC standard colorimetric descriptions might be a 
workaround inside a CMS.


kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 2/2] Move the EDID parsing to its own file

[Kai-Uwe Behrmann]

Am 02.05.2013 23:33, schrieb Richard Hughes:

---
  src/Makefile.am  |   2 +
  src/compositor-drm.c | 180 +--
  src/compositor.c |  21 ++
  src/compositor.h |   5 ++
  src/edid.c   | 175 +
  src/edid.h   |  48 ++
  6 files changed, 254 insertions(+), 177 deletions(-)
  create mode 100644 src/edid.c
  create mode 100644 src/edid.h

+   /* get primaries and whitepoint */
+   edid-primary_red.Y = 1.0f;
+   edid-primary_red.x = edid_decode_fraction(data[0x1b], 
edid_get_bits(data[0x19], 6, 7));
+   edid-primary_red.y = edid_decode_fraction(data[0x1c], 
edid_get_bits(data[0x19], 5, 4));
+   edid-primary_green.Y = 1.0f;
+   edid-primary_green.x = edid_decode_fraction(data[0x1d], 
edid_get_bits(data[0x19], 2, 3));
+   edid-primary_green.y = edid_decode_fraction(data[0x1e], 
edid_get_bits(data[0x19], 0, 1));
+   edid-primary_blue.Y = 1.0f;
+   edid-primary_blue.x = edid_decode_fraction(data[0x1f], 
edid_get_bits(data[0x1a], 6, 7));
+   edid-primary_blue.y = edid_decode_fraction(data[0x20], 
edid_get_bits(data[0x1a], 4, 5));
+   edid-whitepoint.Y = 1.0f;
+   edid-whitepoint.x = edid_decode_fraction(data[0x21], 
edid_get_bits(data[0x1a], 2, 3));
+   edid-whitepoint.y = edid_decode_fraction(data[0x22], 
edid_get_bits(data[0x1a], 0, 1));
+



+#ifndef _WESTON_EDID_H_
+#define _WESTON_EDID_H_
+
+struct weston_edid_color_Yxy {
+   double Y;
+   double x;
+   double y;
+};


Why is the Y value set when it is all about primaries. No one will ever 
use that other than for assuming 1.0 .


kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 5/5] Move the optional output name property from drm_output to weston_output

[Kai-Uwe Behrmann]

Am 02.05.13, 10:10 +0100 schrieb Richard Hughes:


In the future the CMS plugins will need to read the config file and setup a list
of hardcoded names to ICC profiles.


Why will come a need for a CMS to read hardcoded names from the config 
file?


kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [patches] Add a color management framework to weston

[Kai-Uwe Behrmann]

Am 03.04.2013 21:47, schrieb Richard Hughes:

Patch 1 adds the framework code, patch 2 adds the ability to load CMS
modules, and patch 3 adds a CMS module written for colord. With those


People have a hard time to understand ICC and colour termininology. So 
some annotations to that first.
A CMS module for a CMF. That is in conflict with your explanations. You 
defined colord as a CMF but call it a CMS module (one which can do by 
your definition colour conversions like ColorSync, WCS or Oyranos). But 
the colord API can not do any colour conversion as would be typical for 
a CMS.


You weston code is outlined as a CMS not a CMF (in your terminology), 
because you link against a CMM.


In case you like to provide the device configuration side only, then 
lcms is not needed at all.


In case colour conversion is part of the plan for weston, then calling 
this code a CMS is spot on.


To the actual code,
Parsing of ICC profiles inside weston is not nice. That would be better 
abstracted out to lay inside the CMS plugins. Those CMS plugins can link 
against lcms or whatever CMM they prefere.



I've left a wodge of documentation in src/cms.h explaining all the
terms and the general idea on how I think this should work. There are


You explain the term CMF. The first idea, which pops to my mind, is 
the Colour Matching Function, which is fundamental to the CIE and ICC 
specs. Are you aiming to do spectral imaging in weston?


kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[Desktop-packages] [Bug 1019010] Re: Chromium does not pick up the system monitor profile

[Kai-Uwe Behrmann]

confirmed for Android and chrome 25.0.1364.172 on Ubuntu-12.10.

The --enable-monitor-profile appears to be a Windows only thing.

Workaround: use FireFox

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1019010

Title:
  Chromium does not pick up the system monitor profile

Status in “chromium-browser” package in Ubuntu:
  New

Bug description:
  Theoretically, chrome (and therefore chromium) is supposed to pic up
  the system monitor profile when --enable-monitor-profile is specified
  on the commandline.

  But when I compare standard sRGB images in Chromium with the display in 
Firefox which is fully CM aware it is clear that the system profile (available 
via the X atom _ICC_PROFILE) is ignored.
  That makes this browser useless on wide gamut screens

  ProblemType: Bug
  DistroRelease: Ubuntu 12.04
  Package: chromium-browser 18.0.1025.151~r130497-0ubuntu1 [modified: 
usr/bin/chromium-browser]
  ProcVersionSignature: Ubuntu 3.2.0-26.41-generic 3.2.19
  Uname: Linux 3.2.0-26-generic x86_64
  NonfreeKernelModules: nvidia
  ApportVersion: 2.0.1-0ubuntu8
  Architecture: amd64
  Date: Thu Jun 28 22:15:22 2012
  Desktop-Session:
   DESKTOP_SESSION = xubuntu
   XDG_CONFIG_DIRS = /etc/xdg/xdg-xubuntu:/etc/xdg:/etc/xdg
   XDG_DATA_DIRS = /usr/share/xubuntu:/usr/local/share/:/usr/share/:/usr/share
  Env:
   MOZ_PLUGIN_PATH = None
   LD_LIBRARY_PATH = None
  InstallationMedia: Xubuntu 12.04 LTS Precise Pangolin - Release amd64 
(20120425)
  SourcePackage: chromium-browser
  UpgradeStatus: No upgrade log present (probably fresh install)
  chromium-default: CHROMIUM_FLAGS=--enable-monitor-profile
  modified.conffile..etc.chromium.browser.default:
   # Default settings for chromium-browser. This file is sourced by /bin/sh from
   # /usr/bin/chromium-browser
   
   # Options to pass to chromium-browser
   CHROMIUM_FLAGS=--enable-monitor-profile
  mtime.conffile..etc.chromium.browser.default: 2012-06-28T22:11:09.110846

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1019010/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Bug 1019010] Re: Chromium does not pick up the system monitor profile

[Kai-Uwe Behrmann]

confirmed for Android and chrome 25.0.1364.172 on Ubuntu-12.10.

The --enable-monitor-profile appears to be a Windows only thing.

Workaround: use FireFox

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1019010

Title:
  Chromium does not pick up the system monitor profile

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1019010/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: Setting the Xorg gamma ramps

[Kai-Uwe Behrmann]

Am 12.03.2013 17:44, schrieb Richard Hughes:

wondering how we should be doing this using wayland / weston. I
appreciate we'll be doing the advanced sRGB-native gamut mapping as
some kind of sub-surface, but this device calibration state is
orthogonal to that. Most existing display ICC profiles encode a


*Additional* instead of *orthogonal* would be more precise, as the 
advanced calibration gamma curve adds to the ICC profile's internal 
gamma curve. Additional means in this context, the Xorg calibration 
curve reduces tonal range in a 8-bit per channel pixel pipeline, as it 
operates entirely in 8-bit precission. While a ICC colour transform can 
be applied to 16-bit data and then sent as 8-bit using all available 
bits and avoid banding artefacts.



calibration RGB gamma ramp in them (the 'vcgt' tag) and the profile is
not valid unless the device matches the calibration state.


Sad, but true. Better are ICC profiles, which omit the vcgt tag 
alltogether. That is much more straight forward IMO.


kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC Weston 00/10] Sub-surfaces v2

[Kai-Uwe Behrmann]

Am 07.03.2013 11:44, schrieb Pekka Paalanen:

On Thu, 07 Mar 2013 07:25:17 +0100
Kai-Uwe Behrmann k...@gmx.de wrote:

The biggest improvement over v1 is that we have some thought-out
commit behaviours. It is possible to resize a window so that all
surfaces stay in sync on screen, and it is also possible to have
sub-surfaces running on their own (i.e. without commit the
parent surface, too).


What is the default behaviour of repainting in regards to Z-order? Draw
all surfaces? I other words, is the possibility to have sub-surfaces
running on their own only optional?


Sorry, I don't understand the question.

In v2 proposal, which does not support nesting, all sub-surfaces are
siblings. They have no effect on each other's rendering. Also, as they
are all siblings, Z-order is a completely orthogonal attribute to
commit mode or rendering.

Nesting support is coming, though.

Could you rephrase the question?


I will try.

Statement:
The flattened output of overlapping transparent regions depend on the 
intented order of painting the graph during compositing.


Question:
Does your following annotation has a side effect on the painting(Z) 
order of transparent content?


 and it is also possible to have
 sub-surfaces running on their own (i.e. without commit the
 parent surface, too)

kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC Weston 00/10] Sub-surfaces v2

[Kai-Uwe Behrmann]

Am 07.03.2013 12:56, schrieb Pekka Paalanen:

On Thu, 07 Mar 2013 12:32:21 +0100
Kai-Uwe Behrmann k...@gmx.de wrote:



Statement:
The flattened output of overlapping transparent regions depend on the
intented order of painting the graph during compositing.

Question:
Does your following annotation has a side effect on the painting(Z)
order of transparent content?

   and it is also possible to have
   sub-surfaces running on their own (i.e. without commit the
   parent surface, too)



Committing new state to surfaces, and compositor's repainting are quite
orthogonal. The compositor is free to repaint as often or seldom as it
wants. Committing does not affect the Z-order or repainting order,
unless you explicitly change the Z-order with a place_above/below
request.


Ok, I now understand the difference between paint and commit. That makes 
sense and answers my question.


thanks and kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC Weston 00/10] Sub-surfaces v2

[Kai-Uwe Behrmann]

Hello Pekka,

Am 22.02.2013 16:07, schrieb Pekka Paalanen:

- A totally new demo client presenting sub-surfaces, including
   Cairo-image rendered window with a pure EGL/GL widget in a
   sub-surface, running independently, but still without glitches
   on resize (sans bugs).
   http://people.collabora.com/~pq/subsurface-2.png


The above example shows non overlapping regions. For a more throughout 
test, I would expect overlapping regions with and without alpha to test 
Z-order behaviour.



The biggest improvement over v1 is that we have some thought-out
commit behaviours. It is possible to resize a window so that all
surfaces stay in sync on screen, and it is also possible to have
sub-surfaces running on their own (i.e. without commit the
parent surface, too).


What is the default behaviour of repainting in regards to Z-order? Draw 
all surfaces? I other words, is the possibility to have sub-surfaces 
running on their own only optional?


kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [Lcms-user] sRGB with unintended D50 whitepoint

[Kai-Uwe Behrmann]

Am 25.02.2013 19:09, schrieb Pascal de Bruijn:
 On Tue, Oct 16, 2012 at 1:43 AM, Graeme Gill gra...@argyllcms.com wrote:
 Pascal de Bruijn wrote:

 Another peculiar fact is that Argyll's iccdump reports this:

 tag 0:
sig  'desc'
type 'desc'
offset   288
size 140
 Unable to read: 1, icmTextDescription_read: ScriptCode string too long

 You get that if the Mac ScriptCode string is  67 bytes.

 From the ICC V2.4 spec, section 6.5.17:

 The localized Macintosh profile description contains 67 bytes of data, of 
 which
   at most count bytes contain a ScriptCode string, including a null 
 terminator.
   The count cannot be greater than 67.

 Thanks.

 We're still getting reports of print services (saal digital) ignoring
 our embedded profiles. While we haven't gotten any concrete
 information as to why this may be happening, one difference are these
 ScriptCode strings.

 So I'm wondering if we can force lcms2 to not embed these strings, so
 we can ask a user to give it a try?


It is usual to use low level tools by people who know what they do for 
non standard editings. Tried IccXML?

kind regards
Kai-Uwe

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [fltk.general] EDE/FLTK talks on FOSDEM

[Kai-Uwe Behrmann]

Am 10.02.2013 23:39, schrieb Sanel Zukan:
 [2] http://edeproject.org/slides/fosdem-2013-fltk.pdf

FLTK CinePaint is still in the (stalled?) starter phase and far away 
from production use. It's appearance in the FLTK application list makes 
a qualified laughter.

kind regards
Kai-Uwe

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: Developing a core shell protocol

[Kai-Uwe Behrmann]

On 11.02.2013 11:06, Pekka Paalanen wrote:
 I want to make sure again, that when we talk about shells in Wayland,
 we usually talk about public shell interfaces in the protocol. Therefore
 all of Linux desktop, regardless of DE or its components (KDE, Gnome,
 gnome-shell, kwin, ...) are under the one and same shell for desktops.
 This is about the generic shell interfaces towards all applications, of
 course, that can somehow make sense on any DE.

Not exactly. Android, Ubuntu and KDE publicly aim to work on all form
factors. How will a desktop only wl_shell, as you outlined, serve those
projects concepts?

To illustrate a bit: attaching a monitor or TV, keyboard and mouse to a
phone is all what is needed for a desktop. That is long on the software
agenda. The difference for phone, TV, desktop computers and so on is
fading away quickly. These devices will more and more run on similar
computer hardware and their CPU/GPU fits already in a USB stick.

kind regards
Kai-Uwe
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [Lcms-user] Order of processing in simple profiles

[Kai-Uwe Behrmann]

Am 05.02.2013 18:33, schrieb Pascal de Bruijn:
 Most profiles have several components, like for example gamma curves
 and an xyz matrix.

 I've always had the impression that transformes are applied like so:

 RGB data - gamma curves - XYZ matrix - XYZ PCS

 Is that correct? Or are the curves applied after the matrix?

For a matrix shaper profile that's correct if the profile is used on the 
input side. For a matrix shaper profile on the output side the order 
will be reversed.

kind regards
Kai-Uwe

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: Color Management in KDE

[Kai-Uwe Behrmann]

 when
neither are installed.  This would make the eventual Qt5 migration easier, and
maybe influence the Qt5 api.


Let me outline point 4) and what I expect that to become:
colord is mostly a small API for DB queries. The DB itself is otherwise 
hidden. The outlined project will need many own code to implement the 
basic device and driver configuration detection. Or it can choose to 
ignore aspects leading to a poor implementation. As soon as one has 
written all the needed code for KDE or Qt it needs to be continued for 
each other supported platform. Thats the logic. In the end it means 
parts of Oyranos or GCM get rewritten in a Qt specific style. All 
remaining Linux DE's have to rewrite everything by themself too. The 
actual Gnome CM (colord) way makes a massive repeat of code necessary. 
IMO that is a waste of programmers energy. Because KDE/Qt will for sure 
not provide a shared API suitable for any Gtk/EFL or other DE project 
out there.


In my expectation the benefit for KDE will likely be relative small, 
because it can not much cooperate with other projects this way.


Let me add:
5) KDE implements a own CMS based on available standards and specs. That 
way it is completely independent, while remaining compatible with 
existing CMS on many levels. It takes away ambiguity and a clean Qt 
style is straight forward possible.


It takes many disadvantages from 4) but on the positives is a kind of 
clean room implementation. Certainly it demands lots of work, but maybe 
not much more or even less than 4).



Obviously my recommendation is for option 4 to be implemented for KDE 4.11.
This could be based on the existing Calligra API.  I'm not sure how much time
I'll have to work on this myself, but it seems to me less work for apps to
work on this together instead of each one re-implementing the same code.

Let me be clear though, if an app wishes to use Oyranos directly as a hard
requirement because of some better functionality or less code then they are
free to do so, but it does come at a cost that they need to be aware of, a
cost which I don't think belongs in kdelibs or Workspace.


Hmm, reads like a plan to abstract from the Oyranos abstraction API. 
Maybe a graphics scheme could help in making that idea better 
understandable?



Thoughts?

John.


kind regards
Kai-Uwe Behrmann
--
www.oyranos.org

Re: Color Management in KDE

[Kai-Uwe Behrmann]

On 22.01.2013 17:50, Cristian Tibirna wrote:
 On Monday 21 January 2013 21:22:42 John Layt wrote:
 My big concern is that KDE is sleep-walking into a hodge-podge
 solution with little co-ordination on implementations and dependencies, and
 little knowledge of the implications of the decisions being made.  I've
 tried to come up with a logical pragmatic solution within the usual KDE
 standards and architecture, but I am not a CM expert so if you feel that
 I've got anything wrong or misunderstood the situation please don't
 hesitate to call me on it.
 I guess I understand that a very color-conscient application (like, say, 
 krita), will need to correctly support CM internally, particularly if the app 
 is used outside an integrated KDE session. But then, is there conflict when 
 both the application and the wm try to manage color?

 - you mention a few hypothetical developments (especially in relation with 
 Qt5). Do you have direct information on the plans? Or, in other words, what 
 is 
 the perceived probability that your future-projections could be defeated by 
 predictible developer-opinion/development-direction changes?

 Thanks a lot.

A infection hit me. So, I am not able to check things and answer much
for some days.

kind regards
Kai-Uwe
-- 
www.oyranos.org

Re: [fltk.general] OpenGL + widgets

[Kai-Uwe Behrmann]

Am 13.01.2013 21:59, schrieb Christopher James Huff:
 Is there a recommended approach to drawing FLTK widgets inside or on
 top of an OpenGL window?

 or
 somehow draw widgets to an image which is then drawn in OpenGL (could
 an existing driver easily be modified to do this?). Are there other

FLTK allows to draw to an offscreen buffer. glDrawPixels() or if you 
need shaders, then better glTexImage2d and friends can bring them into 
OpenGL.

Search for fl_create_offscreen(), fl_begin_offscreen, fl_read_image, 
fl_end_offscreen. Some not so self contained code for a rough idea[1].

kind regards
Kai-Uwe

[1] 
http://www.oyranos.org/scm?p=oyranos.git;a=blob;f=src/examples/image_display/Oy_Fl_Group.h;h=0e0cfd77759f198fd8bf7f7c3fb63009870750e3;hb=HEAD#l196

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

[ANNOUNCE] libXcm-0.5.2

[Kai-Uwe Behrmann]

This is a maintainance release of libXcm, the X11 Color Management
library. The package contains some build and protocol improvements.


Changes Overview:
* support for automake-1.12 (Jan Engelhardt)
* support build dir != source dir (Jean-Sébastien Pédron)
* add XcmConfig.cmake
* add make debian target
* define XCM_COLOR_SERVER_MANAGEMENT enum
* describe ICM in X Color Management spec


About:
The library communicates X colour regions between server and clients,
which is described in the included X Color Management spec.
EDID data can be fetched through i2c communication.
EDID data can be parsed for identification and access to colorimetric
calibration data.
libXcm helps in observing known X11 colour management events.


Known applications using libXcm:
The library is used by KolorServer and CompIcc, a Compiz plugin, for full 
screen colour correction in hardware. libXcm allows to support

multi monitor and multiple regions per window. The Oyranos Colour
Management System uses the EDID parser. QCmsEvents applet observes and
displays colour management events in a nice GUI. Xcm contains three
command line tools for EDID fetching, EDID parsing and event observing.


ChangeLog:
http://www.oyranos.org/scm?p=xcolor.git;a=shortlog;h=refs/tags/libXcm-0.5.2


Thanks to all contributors.


git:  git://www.oyranos.org/git/xcolor
git sha1: 7a6ef7d159bdf364da2b0b61032fa43629ad4f07
package:  
http://downloads.sourceforge.net/project/oyranos/libXcm/libXcm-0.5/libXcm-0.5.2.tar.bz2
size: 301813
md5sum:   4d4f2ad9cdea8d4a9eb6723d86d31016  libXcm-0.5.2.tar.bz2
sha1sum:  040ad16540418052e8c4cea9bfedc6f11305c924  libXcm-0.5.2.tar.bz2


regards
Kai-Uwe Behrmann
--
www.behrmann.name www.oyranos.org___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: Sub-surface protocol

[Kai-Uwe Behrmann]

Am 18.12.2012 06:40, schrieb Bill Spitzak:

On Dec 17, 2012, at 5:01 PM, John Kåre Alsaker wrote:


Then a client such as gimp could draw all it's display into a single buffer.
To get the different color correction of the center display, it would
declare a subsurface containing this and set it's color correction
differently using the wayland api. This would only allocate one buffer,
which would save memory, but more importantly it should make internal code
in gimp easier as you could work around a toolkit that assumes only one
output buffer.

My approach to color correct rendering in Wayland is to let the
compositor handle it and have the clients simply specify which color
space they are using. Only the compositor can render clients correctly
when they are displayed on multiple monitors (unless we introduce a
way to set a buffer per-output).


Yes this is what I am assuming.

What I am asking is if it makes sense for a client to draw two different color 
spaces into the same buffer. The larger area is color space A, and a 
rectangular subarea is color space B. It then tells wayland to make the main 
window color space A, and then makes a subwindow with the clipped subarea and 
tells wayland that it is color space B.


That is how the X Color Management spec implementations communicate 
between clients and servers. Take a window handle and tag it with a 
region, which in turn points to a ICC profile. I think Martin had a 
similar idea to place regions on own textures for KWin some time ago.



The reason is to save buffer space, and also to work around toolkits and 
drawing api's where it is a lot more practical to draw everything into the same 
buffer.


For this reason Xcm adopted the per region tagging approach. Qt and Gtk 
people tould us, they do not like to expose subwindows.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Sub-surface protocol

[Kai-Uwe Behrmann]

On Tue, Dec 18, 2012 at 10:45 AM, Kai-Uwe Behrmann k...@gmx.de wrote:

Am 17.12.2012 16:47, schrieb Richard Hughes:

On 5 December 2012 14:32, Pekka Paalanen ppaala...@gmail.com wrote:


One of the most important use cases is a video player in a window. It
has XRGB or ARGB window decorations, usually the video content in YUV,
and possibly an ARGB overlay for subtitles etc. Currently, the client
has to color-convert the video, and merge it with the decorations and
subtitles, before sending the grand ARGB buffer to the compositor.



A subsurface idea was what Øyvind and I
were discussing at the OpenICC hackfest when we were talking about
tagging a surface with a known ICC profile. This would allow a toolkit
to declare a window area to be AdobeRGB or some home-created camera
profile from a jpeg that has been tagged with an embedded color
profile.



Sounds natural to help with CM compositing needs and was therefore discussed
[1] for OpenICC's Color Management Near X project in 2008.

However, we had seen quite some objections around subwindows at that time.
Did something substancial change on that matter?

I don't see anything there that applies to Wayland. The link to the
original proposal is also dead.


the old thread starter from Tomas for reference: 
http://www.spinics.net/lists/xorg/msg35268.html



To put the question in other words, do Qt and Gtk developers now or soon
play with the idea to use wayland as the internal compositing core?



I believe both have paths to use subwindows/subsurfaces for video and
OpenGL. These can probably be used for clients with special needs,
such as image viewers and editors which would simply attach an ICC
profile to the subsurface. For compositing they could use subsurfaces
to optimize scrolling performance. I expect that to happen with
browsers first and I believe Android already does that.


Reads encouraging.


[1] https://mail.gnome.org/archives/gtk-devel-list/2008-June/msg00150.html


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [Lcms-user] Getting the profile whitepoint

[Kai-Uwe Behrmann]

Am 23.11.2012 11:28, schrieb marti.ma...@littlecms.com:
 Kai-Uwe Behrmann k...@gmx.de escribió:

 However cmsSetAdaptationState() works only globally, which makes not so
 much sense for displaying multiple documents with different settings at
 the same time. A API for setting the adaption state per transform would
 be very appreciated.

 Check cmsCreateExtendedTransform()

Richard and Marti,

thanks for pointing out.

kind regards
Kai-Uwe


--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] Getting the profile whitepoint

[Kai-Uwe Behrmann]

Am 23.11.2012 01:33, schrieb Graeme Gill:
 Richard Hughes wrote:
 I thought chad had to be invertable?

 You can invert it in lcms, but typical CMM's
 won't even try. So what's the point in figuring
 out the devices real white point if you can
 never access anything to do with it when you
 use the profile ?

I modified several applications to use the real whitepoint and not D50 
for on screen proofing.

However cmsSetAdaptationState() works only globally, which makes not so 
much sense for displaying multiple documents with different settings at 
the same time. A API for setting the adaption state per transform would 
be very appreciated.

kind regards
Kai-Uwe

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

[Desktop-packages] [Bug 984424] Re: Xerox WorkCentre 6015 wrong colors cups 1.5.2

[Kai-Uwe Behrmann]

The following link suggests it is a vendor driver issue:
http://linuxliberations.blogspot.hu/2012/08/printing-with-xerox-workcentre-6015ni.html

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to cups in Ubuntu.
https://bugs.launchpad.net/bugs/984424

Title:
  Xerox WorkCentre 6015 wrong colors cups 1.5.2

Status in “cups” package in Ubuntu:
  Confirmed

Bug description:
  Xerox WorkCentre 6015 Ubuntu 12.04 cups 1.5.2  sends the wrong colors to 
printer.
  Works well in Ubuntu 10.04 cups 1.4.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/984424/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Bug 984424] Re: Xerox WorkCentre 6015 wrong colors cups 1.5.2

[Kai-Uwe Behrmann]

The following link suggests it is a vendor driver issue:
http://linuxliberations.blogspot.hu/2012/08/printing-with-xerox-workcentre-6015ni.html

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/984424

Title:
  Xerox WorkCentre 6015 wrong colors cups 1.5.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/984424/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Lcms-user] Black Point Compensation

[Kai-Uwe Behrmann]

Am 15.11.2012 15:32, schrieb Andrei Szeghy:
I guess this is more a color question than littleCms.  Regardless, I'm
 trying to understand the effects of black point comp on color correctness
 for in gamut colors.  Tried to come to a conclusion with test, but I get
 mixed results.  

While black point compensation makes pleasing conversions reproducible,
they are colorimetrically not correct. For that one still has the
relative and absolute colorimetric intents.

The scenario is this.  Rgb image has in gamut corporate logo and a photo
 with both in and out of gamut colors.  I apply relative colorimetric
 transform with BPC and the photo improves with a great reduction in
 clipping.  However, the logo has now shifted as well and I can't say it's
 less or more accurate.  Meaning, is some test cases the deltaE with BPC was
 larger and in others smaller.

Try applying different rendering intents on parts of the image?

kind regards
Kai-Uwe Behrmann
-- 
www.behrmann.name www.oyranos.org


--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Openexr-devel] Embed ICC profile

[Kai-Uwe Behrmann]

Hello Gerhard,

the OpenEXR header contains fields for colorimetric primaries. These can
be used to generate a ICC profile with linear gamma. In the opposite
direction one can extract the primaries from ICC profile and put them
into the header of the OpenEXR file, provided that the image is in a
linear gamma space.

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management
www.behrmann.name www.oyranos.org

Am 02.11.2012 09:36, schrieb Gerhard Huber:
 is it possible or is there a standard way to embed ICC profiles with OpenEXR?
 I could't find a way in the documentation, perhaps I missed it?


___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel

[License-discuss] Adobe DNG SDK License Agreement

[Kai-Uwe Behrmann]

Hello,

can there be a light weight answere if the above license is OSI 
compatible?


The full text is here:
http://www.adobe.com/support/downloads/dng/dng_sdk_eula_win.html

kind regards
Kai-Uwe Behrmann
--
developing for colour management 
www.behrmann.name + www.oyranos.org

___
License-discuss mailing list
License-discuss@opensource.org
http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss

Re: Gamma correct rendering with Wayland and Weston

[Kai-Uwe Behrmann]

In reply to John Kåre Alsaker Fri Sep 28 08:52:17 PDT 2012


- srgb:
Rendering in linear gamma:
If the hardware supports sRGB textures:
EGL: Use sRGB textures and present it as linear gamma 
to shaders.
If the hardware doesn't support sRGB textures:
Shader: Convert from sRGB to linear gamma.
- rgb:
Rendering in sRGB gamma:
Shader: Convert from linear to sRGB gamma.


sRGB textures implies supporting the sRGB colour space on textures.
Is such a texture meant to tell the display system to do final colour 
conversion from sRGB to monitor colour space? Are non sRGB colour spaces 
still possible like CIE*XYZ or LStar-RGB.icc for sRGB textures?


However you write only about gamma. That is confusing.
sRGB is defined with colour primaries inside the CIE*XYZ space + gamma 
encoding, that is what you appear to be referring to, and exact viewing 
conditions [1]. Gamma is only one part of the sRGB standard. If you realy 
refere to just gamma, then your functions can not be standard compliant 
and logical you should avoid sRGB or make clear that you only refere to a 
subset of that standard. The term sRGB texture would be highly 
inappropriate for gamma encoding.


Gamma, including the sRGB gamma flavor, belongs to a logical layer called 
gamma correction [2]. On the opposite, colour management needs proper 
knowledge of the used gamma, in order to work properly.


kind regards
Kai-Uwe Behrmann
--
developing for colour management 
www.behrmann.name + www.oyranos.org


[1] http://en.wikipedia.org/wiki/SRGB
[2] http://en.wikipedia.org/wiki/Gamma_correction
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [Development] Retina display support

[Kai-Uwe Behrmann]

Am 20.09.12, 19:09 -0700 schrieb P Bai:

I have a few questions about how to add retina display support to my 
application. I understand by reading an earlier discuss that you can add a few 
lines in the info.plist to enable HiDPI render. That would only work for text 
and standard widgets, right? How about icons and pixmaps? How do I detect if 
the application is running in HiDPI mode? For example if I write an image 
viewer program, how do I know when to draw a high resolution image? I guess I 
can just always force draw the high-res image to the rect of a regular sized 
image, but that would be a huge waste of system resource and performance drag 
when running on non-retina system. Are there any better solutions?


Aren't you seeing the window size in pixels as usual? With that available, 
you would have a generic answere for your kind of question.


kind regards
Kai-Uwe Behrmann
--
developing for colour management 
www.behrmann.name + www.oyranos.org___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

ANNOUNCE OpenICC @ GSoC 2012 results

[Kai-Uwe Behrmann]

We gladly announce, that OpenICC's participation was this year a
great success. All projects finished. Links to them can be 
found on the OpenICC Google Summer of Code 2012 web page [1].


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


KWin Colour Correction
Casian Andrei's KWin changes for ICC style colour correction in the GPU 
are discussed upstream and his code to KolorManager code base wait just 
for approval. The concept follows the X Color Management and CompICC 
implementation. But the result is highly modular and thus very flexible.


Simple Toolkit Abstraction
Nitin Chadas SimpleUI project for XML forms rendering 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.


kind regards
Kai-Uwe Behrmann
--
GSoC admin @ OpenICC.info


[1] http://www.freedesktop.org/wiki/OpenIcc/GoogleSoC2012


PS: interessted in a similar project outside GSoC, then just get
in contact with me

Re: [Lcms-user] TR: How transform specific colors.

[Kai-Uwe Behrmann]

Am 12.09.12, 07:22 - schrieb PILLET Céline:

Hi all,
I got a question about DeviceLink. I got a RGB to CMYK DeviceLink. I want 
control some transformations. Is it possible ? Is it possible to specify an 
input RGB color and output CMYK color associate ?


Did you try the transicc tool woth the -i option?--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] How transform specific colors/ More informations.

[Kai-Uwe Behrmann]

Am 12.09.12, 07:54 - schrieb PILLET Céline:

I know how create a DeviceLink, but i don't know how specify specific colors :
By exemple : I got a RGB color gray( 128 128 128)and i want specify in the 
output device link, that
this RGB color will be transform in a CMYK color cyan (100% 0 0 0 ).
Is it possible ?


That means you need a profiler to create a ICC profile for you. 
Which can later be used by a profle linking tool. Typical 
that involves creation of a CGATS text file, which contains the 
colour association. But those CGATS files are most often created in a 
automatic way and are not recommended to create by hand by novel users.


In case you are still interested look at ArgyllCMS:
http://www.argyllcms.com

A other way, is to provide the table entries of the colour transform 
yourself and create a ICC profile. lcms has API's for doing this on the 
appropriate low level. Using such API for your purpose involves 
interpolating the colours in a programmatic way.

See the API in lcms2.h under cmsStageSampleCLut16bit() and in the manual.

kind regards
Kai-Uwe Behrmann
--
developing for colour management 
www.behrmann.name + www.oyranos.org--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Development] Color Profile support on Qt

[Kai-Uwe Behrmann]

Am 01.08.12, 18:56 +0200 schrieb Olivier Goffart:
 On Wednesday 01 August 2012 18:37:14 Stephen Kelly wrote:
 On Monday, July 16, 2012 14:31:25 alexandros.dermena...@nokia.com wrote:
 Hi,

 Thanks in advance!

 Hi there,

 Given that https://codereview.qt-project.org/#change,31387 has been merged,
 can you post any more information that will last until the QColorProfile
 class can be implemented? Any ideas on API or implementation?

 Argh..  Pointers?!
 I tought it would be like an enum (or an int)

... like copying a small object, which hides the implementation in a 
smart way? It could reference the real profile and on edit it does a copy.

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Lcms-user] Pre and post linearisation curves artifacts?

[Kai-Uwe Behrmann]

Find below a screenshot illustrating the issue:
http://www.oyranos.org/temp/lcms_post+pre_curves1.png

Am 31.07.12, 14:40 +0200 schrieb Kai-Uwe Behrmann:
 While moving the image around inside the Oyranos example image viewer, I 
 observed darker pixels obtaining some random noice. Did someone else see this?
 It goes completely away if the curves option is switched off. The noice does 
 not stick to specual values, but changes with each new colour transform.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] Pre and post linearisation curves artifacts?

[Kai-Uwe Behrmann]

In trying to reproduce the noicy behaviour with tificc, the output was
fine. And after setting OMP_NUM_THREADS=1 the output became fine in 
the Oyranos example image viewer too while using pre and post CLUT curves.

So the noicy behaviour, while using cmsFLAGS_CLUT_POST_LINEARIZATION and
cmsFLAGS_CLUT_PRE_LINEARIZATION, appears to be triggered by threading.

kind regards
Kai-Uwe

Am 01.08.12, 11:55 +0200 schrieb Kai-Uwe Behrmann:
 Find below a screenshot illustrating the issue:
 http://www.oyranos.org/temp/lcms_post+pre_curves1.png

 Am 31.07.12, 14:40 +0200 schrieb Kai-Uwe Behrmann:
 While moving the image around inside the Oyranos example image viewer, I 
 observed darker pixels obtaining some random noice. Did someone else see 
 this?
 It goes completely away if the curves option is switched off. The noice does 
 not stick to specual values, but changes with each new colour transform.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

[Lcms-user] Pre and post linearisation curves artifacts?

[Kai-Uwe Behrmann]

After the recent discussion about linear to gamma conversions, I added support 
inside the Oyranos lcms2 module.

That option brings a good improvement. Already normal sized CLUT's give visibly 
improved results.

While moving the image around inside the Oyranos example image viewer, I 
observed darker pixels obtaining some random noice. Did someone else see this?
 It goes completely away if the curves option is switched off. The noice does 
not stick to specual values, but changes with each new colour transform.

kind regards
Kai-Uwe
-- 
www.behrmann.name

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Development] Color Profile support on Qt

[Kai-Uwe Behrmann (oy)]

Alessandro Portale alessandro at casaportale.de writes:

 
 On Mon, Jul 16, 2012 at 7:07 PM, Olivier Goffart olivier at woboq.com 
 wrote:
  All QPainter operations (at least in the raster engine) assume a 
  linear color
  space. That means that the color conversion need to hapen last, right before
  being shown to the screen. After all kind of blending operations or anything
  done with QPainter.  (That means it could even been done in the platform
  plugin)
 
 Good point. That way may automagically solve the issue with which
 screen (output-) profile to use when painting on a screen. However,
 color transformations are not cheap and may slow down painting. I
 already see all kinds of caching in that area :)

Drawing during displaying on the fly is a typical approach. osX does this
implicitly and always accelerated. On Windows conversion will happen on 
the CPU and only after explicitly requested. For Linux it is/will be a mixture.

  Color conversion should probably also happen when loading images, to convert
  them to a linear color space.  Right now, Qt do no handle color profiles at
  all, so it interpret png for example as plain linear RGB instead of sRGB.
 
 Would the 'linear' RGB in this case be the screen RGB? RGB without a

Sounds quite unusual.

 profile has little meaning in a color management workflow. Imho,

agreed!

 QImage could continue loading the raw rgb-data as-is and
 additionally load/hold the profile of the image (or the very common
 sRgb tag) in order to use that as input profile at the end when
 painting. This would also make sure that there is only one color
 transformation in the (load - display) workflow. Two color
 transformations will cause quantisation artifacts, esp. with 8-data.

Keeping the ICC profile around is a good entry strategy.

   Just a few questions:
   1) Would Qt use (and ship) a color conversion library, or would the
   system library be used where available (e.g. on OSX and Windows)?
 
  Regarding native platform support, we should work together with
  Oyranos developers. While their API is horrible (maybe because it is
  so non-Qt'ish), they have in-depth knowledge about the theory and the
  praxis of color management. Maybe with their expertise, we can create
  a nice API for application developers to interface the platforms.

agreed, a Qt specific abstraction would be desirable for C++ and QImage.

  I'd say Qt should use an external library for that. This problem has already
  been solved, and there is no reason to reinvent the wheel.
  That said, I'm saying that without knowing what are the available libraries.
 
 There are free libraries that do icc profile based color conversions.
 Qt could ship one of those as 3rd-party code. The functionality that
 was missing in any of these libraries -last time I looked-, is a cross
 platform API to get the current system profile for a screen. I did not
 yet look at Oyranos, though.
 
 My 2 cents. If I may sketch a very dirty, basic API set which could
 imho enable different cases for color savvy application develpers:

   QImage::QImage(...) // Constructors would load image input profile
 or standard profile tag (sRgb/Adobe Rgb).

   QICCProfile QImage::profile(); // Returns the original image input
 profile. (Yes, this should be part of QtColorManagement, not QtGui.
 This sketch *is* dirty)

The QICCProfile should at least expose a QByteArray on each platform to obtain 
the raw ICC blob beside the internal description and ICC ID.

   static QICCProfile QtColorManagement::systemProfile(int screenID =
 0); // Return the current system profile for a specific screen (TODO:
 printer?)

That API would need a concept of device listings and driver contexts for 
display outputs, scanners, printers and cameras.

   static QImage QtColorManagement::profileTranformedImage(const QImage
 image, const QICCProfile outputProfile) // The resulting Image data
 is now in the colorspace of a specific screen or printer(cmyk?)

void QtColorManagement::profileTranformedImage(const QImage image_in, 
const QICCcontext conversion, QImage image_out); // Conversions can 
happen in place

   static QImage QtColorManagement::profileTranformedColor(const QColor
 color, const QICCProfile inputProfile, const QICCProfile
 outputProfile) // Transforming single colors.

   ... QPainter would remain color profile agnostic, as it is right now.

For the long plan, I doubt that would be useful. For now it is a big step
forward to store ICC profiles along a QImage as meta data.

Considered can as well a general framework to store IPC, Exif and other
information additional to ICC profile for each loaded image.

 Such an API would avoid all automatic conversions by default, and
 simply provide cross platform helpers for app developers who decide to
 consciously do color management.
 QtWebkit could of course perform color management as Safari does: If
 a loaded image has a profile/tag match it to screen.

The Quartz backend for webkit in Safari tags all 

Re: [Lcms-user] sRGB with unintended D50 whitepoint

[Kai-Uwe Behrmann]

Am 23.06.12, 20:51 +0200 schrieb Pascal de Bruijn:
 We've recently discovered that Darktable's (a photography application)
 internal sRGB profile seems to encode a D50 whitepoint even though we
 are passing a D65 whitepoint. The current theory is that this changed
 when we migrated from lcms1 to lcms2.

The whitepoint goes into the chromatic adaptation tag. D50 is defined for 
v4 profiles in the spec.

Look for some examples on the official ICC website:
http://www.color.org/srgbprofiles.xalter

 Is there any way we could stick with ICCv2 (for greater compatibility)?

The compatibility argument applies to what specific CMM?
Most CMMs support v4 profiles after all these years.

Picking a on disc ICC profile is no option for darktable?

kind regards
Kai-Uwe

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

[fltk.general] replace PNG shared image handler

[Kai-Uwe Behrmann]

Hello,

I see images with ICC profiles [1] being badly supported inside FLTK.
How can I replace the default image handlers with my own ones?
A simple  Fl_Shared_Image::add_handler(myImageCheck);
did not help. The handler is not called for known formats, like PNG. Only 
unknown formats are sen by myImageCheck.

thanks in advance
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org

[1] http://www.oyranos.org/wiki/index.php?title=Test_Images

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] replace PNG shared image handler [SOLVED]

[Kai-Uwe Behrmann]

Am 10.06.12, 14:47 +0200 schrieb Kai-Uwe Behrmann:
 How can I replace the default image handlers with my own ones?
 A simple  Fl_Shared_Image::add_handler(myImageCheck);
 did not help. The handler is not called for known formats, like PNG. Only
 unknown formats are sen by myImageCheck.

The following sequence helped in adding our image handler before the 
default FLTK on:
   Fl_Shared_Image::add_handler(iccImageCheck);
   Fl_File_Icon::load_system_icons();

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org

___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [fltk.general] Antipaint

[Kai-Uwe Behrmann]

Am 07.06.12, 09:26 +0200 schrieb Georg Potthast:

Antipaint is a Paint program based on FLTK and mentioned with a dead link in
the Wiki/Software/Graphics section on the FLTK site.

Mark Roth was so kind to sent me the source code and I got Antipaint to work
with FLTK 1.3.0 and posted the source code here:

http://nanox-microwindows-nxlib-fltk-for-dos.googlecode.com/files/antipaint.tar.gz


The attached patch helped me to build the app under Linux.

kind regards
Kai-Uwe___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Re: [Lcms-user] float types

[Kai-Uwe Behrmann]

Bob Friesenhahn bfrie...@simple.dallas.tx.us schrieb:

Likewise, GraphicsMagick includes work by Richard Nolde which knows 
how to handle 16 and 24 bit floats.  He actually wrote a full 
conversion suite between 16, 24, 32, and 64-bit floats.  I only 
incorporated the specific functions that GraphicsMagick needs.  This 
code has been in GraphicsMagick since 2008.  The code has been 
verified on a wide-variety of CPU types.

24 bit floats are also important because they are supported in the 
TIFF file format, are supported by Photoshop, and because some GPUs 
(e.g. from AMD) support 24 bit floats.

Given the MIT license in GraphicsMagic and little CMS, the GM implementation 
appears just from a license POV more appropriate than BSD licensed code.

kind regards
Kai-Uwe


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Re: [Lcms-user] float types

[Kai-Uwe Behrmann]

Am 31.05.12, 12:16 +0200 schrieb Boudewijn Rempt:
 On Sunday 15 August 2010 Aug, marti.ma...@littlecms.com wrote:
 Quoting Kai-Uwe Behrmann k...@gmx.de:

 Grepping the sources did not show a cmsFloat16Number type. Am I right in
 that Half is currently not supported by lcms?

 Right, still not supported but there are plans to provide formatters
 for that. This is the reason of using a special flag for floating
 point data. cmsFloat16Number and cmsInt16Number would both take
 16 bits per component but the interpretation is completly different.

 Will take some releases to get that, though.

 Hm... I'm starting to get really interested in this at the moment, so I'm 
 wondering if there's any news... I've finally been experimenting in Krita 
 with lcms2's f32 and f64 support, and it works great. But I would also like 
 to support f16, because that's what my users tell me they really need.

OpenEXR Half is the format of choice for movie picture exchange. Support 
inside lcms would bring Half to applications almost for free, with a win 
in memory foot print.

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user