Magic Lantern @ LGM in Leipzig

… on Wednesday April 2nd. Their talk will begin 18:30 o’clock local time in the New Paulinum of the University of Leipzig.

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

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

Movie LUT’s inside ICC Profiles

Krita, a painting application with high dynamic range (HDR) support, is in the planning phase for the next release cycle. One hot topic is currently the discussion about what can be done to make movie makers even more happy. A good candidate is the marriage of film industry colour management with Krita’s inbuilt ICC style colour management. But Krita maintainer Boudewijn Rempt expressed surprise about movie style colour management in other apps.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ICC wants streamlined workflows

The ICC meeting from 30th January to 1th February was again a great chance to meet with colour management people in person. The meeting was hosted in Munich at Adobe with a great view over the snowy city. I joined the sessions under the OpenICC umbrella to represent the open source community.

Of course many talks went over various specification topics and coordination with other standard bodies and groups of interest in colour exchange. But as ICC is evolving, there are new topics coming up as well.

Notably, ICC is slowly moving from a solely static colour content description of what colours are. There is great interest to cover as well the process of applying colour conversions. This covers necessarily definition of terms and workflows and gets to the questions of why, how and who handles colour. This will help users to do high level decisions as opposed to the current need to understand low level technical ICC terms and figuring out how that applies to actual used implementations.

I presented my work inside OpenICC to add monitor identification and calibration state information inside ICC profiles to streamline profile distribution and installation. The concept found support and the presentation about the meta tag keys came along nicely.

ICC members dive currently into spectral imaging, which is prototyped in SampleICC. I appreciate this direction, as it very likely simplifies the use of spectral readings for colour calculations in applications.

The only discussed hint to reduce the size of n-channel profiles, was work on how to put formulas inside the colour processing pipe. It would be great if that comes to a useful result. Formulas inside ICC profiles where first introduced during the v4 specification but only apply to single channels. For per channel operations are currently some few formulas supported. However the new approach allows to express with more elementary operations and allows free access to all channels.

Obviously many members have a strong background in printing, which is greatly reflected in the spec. But some companies have a strong relation to various imaging industries, like camera manufacturers, who as well create printing or displaying devices. There is potential, that ICC will support their interests, provided they actively contribute. For instance ICC profile embedding inside images is well covered inside the ICC spec. That was a good base for e.g. the W3C to introduce colour management for photography on the net. There is no equivalent to movie or video content. In parts embedding of ICC profiles there does not even exist.

Altogether, the ICC meeting was a great chance to coordinate and intensify the work of ICC and OpenICC.

OCIO 1.0.1 released

Jeremy Selan released a new version of the open source color management library OpenColorIO.

Changes:

  • simplification of ocio2icc / ociobakelut
  • bug fixes

About:
Based on development started in 2003, OCIO enables color transforms and image display to be handled in a consistent manner across multiple graphics applications. Unlike other color management solutions, OCIO is geared towards motion-picture post production, with an emphasis on visual effects and animation color pipelines.

Download:
Github

Google Summer of Code Mentors Summit 2011

Last week end from 21th to 23th October mentors meet in San Francisco / US to share our experiences in organising and mentoring students during Google Summer of Code 2011, talk about open source projects and of course get in contact with other teams and meet in person. The Mentors Summit was well organised and it was fun to be there. It was my first time in the south of North America. So chances where good to meet new people.

The VLC and FFMPEG people where interested in colour management. I tried to give them some idea, what colour managed applications need to know about media streams. It seems, that awareness rises about colour management in the open source video community, which is wonderful.

Two members of the Scribus team where present, Peter Linell and Malex. We could discuss quite some topics around distributions. It was great to meet them both.MountainView Google Summer of Code Mentors Summit 2011

The Open Source in Visual Effects was missed be me due to a swapping of rooms. Luckily Peter knew the OpenColorIO author and we could get in contact in a small four people meeting. We discussed Linux colour management, distribution and the relation of movie picture to ICC style colour management. Jeremy Selan pointed out the very difference of HDR scene referred imagery compared to the style of HDR which is typical in ICC workflows. I could convince Jeremy to look at the ICC floating point extension and it’s two open source implementations. He was interested and might work on implementing that in OCIO too. If that happens, it would be a great step toward joining movie with still graphics workflows. In the past the issues around round tripping and HDR handling had lead to the decision of movie studios to develop own colour management systems. OCIO supports already the export of colour correction tables to ICC profiles for use in photo and paint applications, which traditionally feature ICC workflows. Once the input side through ICC profiles is implemented in OCIO the same library could be used as a CMM inside ICC and movie workflows.

Thanks to Google and its OPSO team for sponsoring and organising a great event.SF_near_port_after_GSoC_summit