OpenICC/GoogleSoC2013

From ColourWiki

OpenIcc/GoogleSoC2012 Wiki is intended to collect ideas for possible projects participating in Googles Summer of Code program (http://code.google.com/soc/). Google Summer of Code (http://www.google-melange.com/gsoc/events/google/gsoc2012) timeline is online.

OpenICC wants to bring colour management programming themes to the audience of students. Goal is to understand open source programming and learn how to effectively interact with and contribute to a project in an intercultural environment.

OpenICC is a group of people dedicated to organise how applications, libraries, toolkits and colour devices talk each to the other about colours. The center of this work is the ICC specification, which is surrounded by several general and operating system specific conventions to create a easy to use open sourced colour management system for naive and experienced users.

Oyranos is a implementation of mentioned conventions to cover ICC profile handling and colour conversions. The newBSD licensed code base is plain C. Its core requires very few dependencies, namely libxml2. Device support and colour conversions involve according APIs. Goal is to use existing standard technology like XML, XFORMS and GLSL. Oyranos features a (almost) data independent framework to plug-in data manipulators, for colour conversions, tonemapping, image I/O and other operators into a data processing graph.

Table of contents

About the Group

OpenIcc consist of the participants of the OpenICC email list. It was started by Scribus members to better support introduction of colour management into applications and discuss general issues. List contributors are application and CMS developers as well as colour management specialists and users, no matter whether commercial, open source and both. The main focus of this group is to expand the level of support for color management on open source software systems.


Project Suggestions

Advanced GPU Colour Management

3D and advanced graphics applications want to deploy fast colour correction in several corner cases. The project will help them to use effective stored HDR texture buffers and do blending in linear space for multiple monitors. The goal is to provide working code, which runs fast even on low level devices to increase portability. The project results target at integration into applications, toolkits, compositing window managers and CMM's.

Expectations

  • create a root widget for offscreen rendering of windows (preferred Qt)
  • integrate existing code demo snippets for colour correction on GPU using 3Dtexture lookups
  • integrate shaders for !LogLuv compression and decompression (shader snippets exist)
  • integrate post linearisation LUT's to convert from linear space to monitor gamma
  • render to GL texture using a widely available and portable API or library
  • support multi monitor output (e,g, glScissor)
  • provide sensible clipping of HDR values as optional shader (algorithm exists)
  • demonstrate blending in linear space and final conversion to monitor spaces

Skills

  • good OpenGL knowledge
  • good API design
  • readable, extendable and clean code
  • inline documentation

Contact

  • Mentor: Kai-Uwe Behrmann


Print Queue Setup in KolorManager

Users and administrators want to configure device ICC profiles for print queues to improve colour output. This should be simple and easy. The project aims at making that reachable wit ha few mouse clicks from inside KDE's Color Management configuration panel. Most components are already present and need just to be combined in a user friendly way.

Expectations

  • integrate into KolorManager/Synnefo
  • use Oyranos API's
  • configure PPD print queues
  • modify CUPS print filter(s) as needed to pass through calibration data
  • provide well commented patches to upstream CUPS
  • end user documentation

Skills

  • medium difficult
  • good communication
  • C++, Qt, C, shell
  • git

Contact

  • Mentor: Kai-Uwe Behrmann
  • Adviser: Edmund Ronald


OpenICC Colour Configuration for Linux/BSD

Users, who configure their colour management system (CMS) behaviour and devices, want to share these settings on one host without any intervention among installed CMSes. The project will introduce the OpenICC data base into CMSes like ArgyllCMS, Oyranos and colord and replaces existing own DB access code.

Expectations

  • small, readable and clean code
  • existing code might be reused
  • use yajl library
  • decide about file locations (/etc and in ~/.config)
  • add path if any new is needed to http://www.oyranos.com/wiki/index.php?title=OpenIccDirectoryProposal
  • add DBus interface
  • provide patches for existing CMM'es like ArgyllCMS, Oyranos, colord
  • add end user documentation (inline API docu and man pages)
  • MIT license

Skills

  • rather simple programming tasks
  • good communication
  • C, JSON, make
  • git

Contact

  • Mentor: Kai-Uwe Behrmann
  • Further Advisors: OpenICC email list

Links


OpenICC Colour Configuration for Android

Users, who configure their colour management system (CMS) behaviour and devices, have on Android currently no way to share these settings. The project will introduce the OpenICC configuration scheme into Android.

Expectations

  • small, readable and clean code
  • use Javascript
  • add Java interface usable for other applications
  • detect and identify attached monitors
  • front end application to list profiles, settings and assign a profile from Url to monitor
  • add end user documentation (inline API docu and man pages)
  • MIT license

Skills

  • medium level programming tasks
  • good communication
  • JavaScript, Java, JSON, Android
  • git

Contact

  • Mentor: Kai-Uwe Behrmann
  • Further Advisors: OpenICC email list

Links


OpenGTL-/+OpenCL meta backend for Oyranos

In order to build fast filters in Oyranos a meta backend is to be programmed. It should allow for fast manipulation of image data like colour conversions, tonemapping, blending or geometric transformations.

Expectations

  • study basic concepts of OpenCL shaders, their implementation in Mesa and the Oyranos CMM framework
  • decide for a implementation concept (OpenGTL/OpenCL)
  • work on existing code and integrate your implementation using most of the already available functionality, extent where needed
  • documentation for users - should be very few

Skills

  • basic communication
  • portable C and C++ programming

Contact

Optional

  • convert the available small ICC colour transformation application for demonstration with colour table lockup into a shader plug-in


CMM's for Oyranos

SampleICC is the official implementation of the ICC colour profile standard from members of the [[1] (http://www.color.org|ICC)]. A module of this engine to plug into Oyranos would be cool. An other candidate is ArgyllCMS, which features very sophisticated colour transformations. Qcms is the CMM of Firefox and Chrome, which is a very fast conversion engine. A CMM wrapper can be used to simplify the process.

Expectations

  • wrap the SampleICC (http://sourceforge.net/projects/sampleicc/) API into the Oyranos Colour Matching Module (CMM) API
  • wrap the http://www.argyllcms.com into the Oyranos Colour Matching Module (CMM) API
  • create a catalog of plug-in options supported by the CMM
  • work out test and quality assurance strategies

Skills

  • good communication
  • basic mathematical skills
  • portable C++ and C

Contact


Extending the Oyranos Colour Conversion Framework

. The colour management system Oyranos provides high level means to render colours in a generic way. The advantage is, application developers can rely on Oyranos services without understanding the often complicated details. This project lets you create and optimise various underpinnings of system level to advanced graphic tools. This project is a collection of many small and very versatile tasks. You can freely create a own plan what to do or will be guided according to your level of expertise.

Expectations

Possible targets:

  • implement efficient pixel conversion between arbitrary buffer types (low level C)
  • implement object observation to automatically update to data changes (object oriented C)
  • adapt Oyranos devices to catch outside events (X, dbus, ...)
  • add Create NamedColour (http://create.freedesktop.org/wiki/Swatches_-_colour_file_format) format support
  • implement OS specific CMS connectors to ColorSync and WCS (cross platform)
  • port to Android
  • analyse the concepts behind the Oyranos graphs and suggest means for complete data type abstraction (conceptual work)
  • extent the Oyranos command line tools set to access device and other settings (build upon Unix/Posix)
  • build a small shiny graphical sample application (didactical GUI)
  • agreed upon parts shall be finalised, substitution is possible

Skills

  • depends on what we agree to work on
  • code organisation
  • conceptual fitness
  • good communication
  • work under different OSes (possibly)
  • basic to good C
  • understanding object oriented designs is helpful

Contact

Mentor: Kai-Uwe Behrmann < [email protected] >

Get the cairo color management code upstream

Adrian Johnson did a lot of the work needed to make cairo color managed. Finishing this work and getting the code upstream would allow us to simplify a lot of applications that use cairo. See http://cgit.freedesktop.org/~ajohnson/cairo/log/?h=color-space for the branch. Adrian has also patched Inkscape to use the new features, and that needs cleaning up and pushing upstream http://cgit.freedesktop.org/~ajohnson/inkscape/log/?h=color-space Also see http://lists.cairographics.org/archives/cairo/2012-July/023353.html and https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00084.html for more details.

Expectations

The cairo and inskcape code is pushed upstream with any required modifications. Ideally someone familiar with the cairo community would take this on, as Adrian found it hard to get the code approved upstream.

Skills

Understanding of basic color management, basic use of bzr and git, proficient in C.

Contact

Mentor: Richard Hughes


Add a native i1display sensor for colord

Adding native drivers for popular sensors means we can take color readings without blocking and without screenscraping commands from Argyllcms. I can loan the required hardware for testing and provide specifications for the hardware to write a simple driver.

Expectations

Add a private libi1disp library to colord and write a simple asyncronous sensor driver with a test program. This will be very similar to the libhuey sensor code that already exists in colord.

Skills

Understanding of basic color management, basic use of git, proficient in low level C.

Contact

Mentor: Richard Hughes


Write a self test framework for session display calibration

At the moment colord uses a colord-session binary to present a session D-Bus interface to calibration clients in KDE and GNOME. This allows each desktop to fully theme the calibration experience and use the native UI framework. At the moment, colord supports a dummy sensor that simulates a perfect sRGB screen which responds in a predictable way for calibration. Display gamma correction is not implemented which limits the ability to use the dummy sensor to implement a self test framework.

Expectations

A 'make check' program which sets up the dummy sensor, and runs a calibration in a test harness.

Skills

Understanding of basic color management, basic use of git, proficient in C.

Contact

Mentor: Richard Hughes


ICC profile parser in Javascript

ICC profiles are everywhere. Sometimes people wish to get more information for a particular profile. This project helps in parsing a ICC profile and extracting all interesting information. A HTML viewer shall be able to show that information.

Expectations

  • readable and clean code
  • use Javascript
  • add Java interface usable for other applications
  • write a HTML page to get a ICC profile by Url and display basic information
  • add end user documentation (inline API docu and man pages)
  • MIT license

Skills

  • medium level programming tasks
  • good communication
  • JavaScript, CSS, HTML
  • git

Contact

  • Mentor: Kai-Uwe Behrmann
  • Further Advisors: OpenICC email list

Links


Alternative Ideas

Feel free to propose and discuss your ideas. We highly appreciate your initiative. It is possible to give multiple proposals. Be warned each proposal needs typical time to prepare. The quality of the proposals counts for us to become able to decide.


Requirements

License

BSD, LGPL extended by allowing for static linking are preferred licenses for libraries. GPL and other open source licenses are acceptable for other projects but in most cases the project mentor will specify the license to be used for the project.

Skills

Both good project and coding skills are expected, in order to set up our complex open source projects. We know it is sometimes difficult to talk to people you do not know, especially when they are not visible like over the internet. Nevertheless the mentors of these OpenICC projects want an open dialog with anyone interested in working on these projects. This is an important part of open software development and it is even more important for these Google Summer of Code Projects. Please feel free to contact any of the mentors listed above at any time. The earlier a candidate contacts us the more time remains for getting a feeling of the projects in advance.

Developers Environment

You are free to select whatever build environment you like as long as the project is targeted at that platform. Many of the above projects are targeted at Unix like systems and a few are fully cross platform. Our experience for cross platform projects is that some build environments are more difficult to setup than others. You will also likely find that these projects are significantly more complex than your school projects. For example, the LProf code base is now almost 100,000 lines of C and C++ code.

In order to help candidates be successful in completing their projects it is important that anyone selected is prepared to start actual project work at the project startup date. Please be prepared to have your development environment ready long before the project starts. This means that project mentors will want you to be to able to build and run the base system you are working on well before the project start date. For example, if you are working on one of the LProf projects you should be able to build and run LProf on your development machine at least a month before the project startup date. Windows build environments, in particular, have proven to be particularly difficult to setup and it is common for GSoC mentors to comment about how often the single biggest difficultly for students working on Wndows machines is getting a fully functional build environment setup.

Many open source developers use a unix like environment (IE. Linux, BSD ...) in part because setting up a working build environments is much simpler. This also means that there is a high likely hood that your mentor will not have much experience working in Windows or OS/X and may not be able to provide much assistance to help you get your builds working in those environments. So take this very seriously. On the other hand using a Unix like system like BSD/Linux/osX/Solaris can be a great learning experience for any student who has not worked on one of these in the past. Many big projects run on *nix systems deploying unix concepts and some of the projects listed above are *nix only projects that can not be worked on using a Windows machine. On request we simply expect the programmer to switch to BSD, Linux or osX. The installation should be no issue.

Communication

The OpenIcc list and the mentors for the above projects are all open for having contact with any prospective candidate. We will use a additional public list dedicated to the GSoC projects communication. IRC: freenode#openicc We require frequent direct communication for at least one time per week over email. More is usual better for us to address issues early. Blogging and public discussions are encouraged to interact with the wider community and give them feedback around whats happening.

For any uncovered topics related to the GSoC project please contact Kai-Uwe Behrmann < [email protected] >.