About
wind&oil, Weblog

Syndicate:
Subscribe to a syndicated feed of my weblog, brought to you by the wonders of RSS.

Projects:
www.behrmann.name
www.oyranos.org
ColourWiki
CinePaint

Others Bogs:
Color hacks
mulebakken.net
Linux Photography

Contact
Impressum

home :: cinepaint

Sensible colour clipping
Carl Cole works on a patch to sensibly apply clipping to out of range pixels. The clipping is implemented for the curves and levels tools. In the screencast below you can see how the new clipping works in levels.
CinePaint colour clipping video
And here as screenshot, old wild hue moving towards the three secondary colours:


... and the new levels behaviour preserving hue:


I am pretty shure this behaviour will become quickly standard for open source applications as it is a big quality improvement.

/cinepaint | 2 comments | permanent link |

0.23 swings
After trashing code for a more generic colour rendering core, my gtk development tree is again up and ready.

As usual some colour improvements are included. This means Oyranos is spread more and more over the code. I slowly export CinePaint's colour management to Oyranos. So, CinePaint must at some point rely on it to build. Otherwise I have to provide the bits in two places. The Oyranos dependency will turn mandatory probably already in the 0.23 release.

As well, CinePaint should build by default as a Gtk2 app. Some distribution try to fake the old Gtk1 API by some none useable headers to finally link into Gtk2. As this is non sense for a advanced application like CinePaint, consequently many users experienced failing builds. The configure option --enable-gtk1 should turn the old build mode after the switch.

/cinepaint | no comments | permanent link |

Cmyk versus Rgb printing

It is often discussed, whether Cmyk or Rgb printing results in better quality, or whether one should buy a Rgb or Cmyk device. I will try to shed some light on this theme.

Normally print devices use Cmyk inks. These are cyan, magenta, yellow and black (k). Some come with additional inks for light cyan, light magenta, (light) gray, red and blue to extend the device gamut and improve smoothness. Or they use special finishes for a better appearance of the print. These devices are far away from being Rgb print devices. The somewhat fuzzy term Rgb printer comes almost from the Windows world, where pictures are sent as Rgb colours to print devices. This is a software or driver aspect. The concept, followed on windows, is to make virtually every colour device a (s)RGB device, and thus simplify software and user interaction. This concept has advantages and disadvantages. See further at wikipedia.

To achieve good results, depending on what quality you like to obtain, the colour conversion should occure with colour profiles according to the desired quality and designed for the combination of your device and the ink/media/software/driver you plan to use. Most colour profiles are stored in the ICC format. But there exist as well internal colour transformations in some drivers or propriarity formats. For instance Gutenprint utilises internal lookup tables and algorithms for converting incoming Rgb to printer side Cmyk colours.
As Cmyk is often almost the native colour space of your printing device, this colour space is often used in professional grade RIP's to better deploy the gamut of a printer.

An other aspect is the look of your print. This includes saturation enhancements or a special tint of the sky, skin tones and so on. It is the aspect of taste in this art, varying with the region and the group of persons.

For CinePaint, the image separated into Cmyk colours, will transport the high bit depth colour information in a most straight forward manner to the Gutenprint print driver. Thus Gutenprint has just to dither with few further colour conversions, resulting in less banding and finer gradients for sky, foggy motives and the finishes on glass and car surfaces. Of course you have the option to use the Gutenprint internal conversion routines and supply Rgb, thus by-passing the ICC conversion. You can read more about printing in CinePaint in my CinePaint - 16-bit Imaging tutorial.

/cinepaint | no comments | permanent link |

Retargeting 0.22-1 changes
As I released today the 0.22-1 bugfix version, the changes mentioned earlier on this site must be delayed. Lets see as well, if I can get the Python plug-in working to make it a useful distribution part.

/cinepaint | no comments | permanent link |

Grafpup 2.0
and Nathan could not resist to include UFraw allready. Funny. Hope many users enjoy like him: in his news.

/cinepaint | no comments | permanent link |

0.22-1 tasks for Oyranos
Now that the release of CinePaint is out, some things come clearer or simply more evident for handling colour management with Oyranos.

Gray default profile
One thing is the a missing default profile for gray images. I am now adding this to Oyranos. Without it would be incomplete.

Maximum conformity
The other thing is the missing policy display. If I remember correctly something like a first warn message should be implemented. But it seems difficult for a user to understand such messages the first time. Let me explain a bit more. Once Oyranos is installed and CinePaint runs all comes smoothly. A PNG is opened and and gets a default profile assigned. As the Home+Office policy is the first active one. It will be sRGB for untagged data. Fine. The user tweaks that and saves. Now a tiff comes its way and opens nicely, editing, saving. No problem. After sending to a agency they phone and say it was degraded from their accepted WhateverRGB to sRGB. Now what? No message appeared. Repeating the same in CinePaint and looking now carefully on the windows top border, one can observe that there is sRGB right from the beginning.
Thats not possible. CinePaint degrades an image and this silently. Where is the professionalism?
You can imagine, this will provoke many colour people.
Indeed Oyranos first hand policy is a keep it simple policy. Convert all to sRGB and make all the same right from the beginning. The intention is to help that many users without colour ambitions to work without the need to understand colour management. Once a image is loaded in a Oyranos compliant application, every other applicatin should handle colours fine. This is a maximum of compatibility.
For colour people it is simple to change this. In Oyranos' control panel, called by oyranos-config-fltk, one has simply to switch from Home+Office to say Photographer. It is in the first tab. Now your image data are handled much more carefully. No colour space degradiation to sRGB, and a bigger default editing colour space is now active.

The dilema is about making it really good for both unexperienced and high level users. Policies can help to satisfy many different groups. And in the future one can simply create its own policy. But a application author is under pressure to provide success right from the beginning.

The question which arises is, how should a default for a fresh installation be formed? What is acceptable for all as a first start?

/cinepaint | 3 comments | permanent link |

Blackpreservation
This print plug-in in CinePaint's interfacing with Gutenprint is available since quite a time. The blackpreservation option can be found in the first print dialog in the lower part. It affects only CMYK-CMYK conversation. Below is a colour conversion from a ISOcoated to a desktop inkjet with very different gamut shown. The inkjet's black has a brownish shade. The screenshot shows the visual output on screen:
It is not perfect, but gives you an idea what is available now. The on the fly creation of the device link happens in the background within littleCMS (or lcms), CinePaints internal used colour management modul.

/cinepaint | no comments | permanent link |

Smoothness
of the brush strokes seems limited. The blue may camouflage. Anyway for a non vector drawing it is ok. Now scaling works correct:

/cinepaint | no comments | permanent link |

Linux Tage Chemnitz 2007

This years the fair in my hometown was a nice experience. 40 people, all beginners, where listening to my, in their eyes somewhat exotic, colour management and CinePaint explanations. They where probably attracted by the title. I must admit, my intention was to have a discussion with specialists, but these people seems not to come regulary to Chemnitz. But with a small change I hope the audience could take a good impression home.
Beforehand I tried to bring the CinePaint release out, but found some no go issues. Now, with the nice feedback from the fair, I started to solve a long outstanding thing - the precission in the drawing core. The inherited code does nice things, but is, well, a not finished kernel. What I want is a polished look of brush strokes. Things which dont belong to a stroke must go away. What I found is − the CinePaint engine lacks precision in drawing positioning. Some code snippets to overcome the resulting effects are found but where never finished. I looked at the continued projects and thought, it would be best to stay within the CinePaint code complexity and not switch to the complexity of an other application. The results can been seen below.
Drawing quality before (left) and after the changes (right):
There should be still more done to better work out of the box. As well these changes made some other things obvious − see the stripes in the blue stroke. As well the brush scaling code is now insufficient. Hmm ... an other delay in the release. Btw. as you might have noticed the tablet issue for Gtk2 is fixed.

/cinepaint | no comments | permanent link |

Gtk CinePaint release target
January has long gone. What is left, to do a 0.22 release, is to integrate Alan's patch and convert the brushes to something readable by CinePaint.
I am shy to touch the code and convert to OpenEXR as new brush format, as long as Oyranos 0.1.7 is not out of the door.
Probably the new theme will find its way into CinePaint's toolpanel.

/cinepaint | no comments | permanent link |