The weather’s been getting warm out here in my part of the Northern Hemisphere. It’s a tempting thought to spend each day at a beach and enjoy the relaxing, cool sounds of ocean waves… but there’s coding to be done!
So here’s the Week 3 update:
In getting the libCmpx/Krita GSoC project closer to its integration phase, I spent the entire week tuning up the library‘s PDF rendering module. This module is all about PDFs, which is a good thing because PDFs will become the spool format used for printing in Linux. This means that every image that you “Print…” in your application will eventually end up as a PDF file by the time it reaches your print server. The aim of libCmpx’s ‘Renderer’ module is to make sure that whatever ICC profile you (or libCmpx’s ‘Selector’ module) choose in a print dialog, it gets used along with the PDF print spool file.
Above is a graphic outlining how the Renderer module is used in the test dialog. One important task this module is assigned to is in the creation of an ICC profile-simulated preview image. If you load a PDF file in the test dialog, getImagePreview() is invoked to generate an “After” image of the file. When using the “ICC color profile” combobox to import a profile — which must be done in this fashion, since at the moment the dialog will only guarantee previewing profiles that you select by hand — Renderer will have Ghostscript create a TIFF preview file using that profile for output. This is a feature that can be beneficial to Krita users, as seeing a rough color sample of the image before it’s printed will save precious ink!
LibCmpx Renderer is also responsible for embedding an ICC profile onto the PDF spool file. This is a required step in the Linux color-managed print workflow, since the color profile information must be transported in some fashion through CUPS. Ghostscript is especially useful in that regard, as it is able to both attach and extract profile data stored in a PDF file (the latter is actually performed from within CUPS). When you click “Print”, a call to setSpoolPdf() will handle modifying* the PDF so that it is color management-aware, meaning that the color profile is embedded in the document and that the proper colorspace has been tagged.
While I have made great strides last week in fixing up Renderer and implementing the new image preview mechanism, more work needs to be done to ensure that errors in this module are put to a minimum. So I will continue to fine-tune the module for next week and eventually enable the “Print” button in the test dialog.
*Don’t worry. No changes are made to the file that you selected in the test dialog. A copy is actually created and sent to libCmpx for processing.
Here’s a quick update on what’s been happening with the printer color management project for Krita.
Since last week, much of the work was focused in providing a “communication” link between the individual print dialog settings and the libCmpx Selector module. I have just pushed a major commit today for the library that should tightly bridge the two together, allowing Oyranos (housed inside libCmpx Selector) to properly read these settings and process an appropriate ICC profile. With a little more testing and fine-tuning in the module, half of libCmpx will be ready for integration with Krita.
The next few weeks will focus on the second half of the library, which is the PDF spool rendering module (libCmpx Renderer). Work has already started this week in creating a print preview mechanism in the Renderer module, where Ghostscript will create a color-managed, PNG preview of the PDF spool file.
Google Summer of Code has officially started this week, along with the more critical pieces of work for libCmpx. The timeline that I had planned for the summer is to get libCmpx up to snuff during the first half, and then to integrate the library into Krita during the second. The latter goal should proceed smoothly if the former has been worked on with care.
This week, I concentrated on extending the libCmpx API to handle obtaining each print option individually.
Originally, the library was only able to obtain printer options that were marked directly from the print driver file (in Linux, “ppd_file_t” for PPDs). Such a case was convenient only if the driver files were readily accessible from the print dialog application. In the case of print dialogs like Krita, however, these driver files are usually abstracted away from the dialog programmer. This meant that a better approach for libCmpx is to extract each option string from its corresponding widget.
As shown in the above visual, each option in the print dialog simulator will “hook” onto libCmpx using a function call – “libcmpxCM_setPrintOption()” – which will internally store an option as a key/value pair. Processing of these options to obtain a profile is emitted by the “libcmpxCM_calibrateICC()” function. What happens in “auto assign” mode is each color option will be sent into libCmpx’s Selector Module, which will then use Oyranos to rank an appropriate profile based on the selected options. The user gets full priority for selecting profiles manually, so such processing will not happen for cases like that.
So far, this API addition is partially implemented, but I hope to have this finished soon. During this stage of work, the print dialog simulator will be broken in the meantime, so please bear that in mind if you have been testing it!
The above screenshot is that of the color-managed print dialog simulator that will be used throughout the Krita/libCmpx GSoC project. Although it is now ready for public viewing and testing, it does not do much at this point. It will eventually become a little more “smarter” throughout GSoC, as continued work on libCmpx will change the dialog’s behavior so that selecting a certain “ICC color profile” setting will correctly adjust the other settings.
Once this simulator becomes intelligent enough to automatically select ICC profiles and render print-ready PDF files, libCmpx will be ready for Krita.
I will soon be writing more posts related to this test dialog, since it provides an excellent vehicle in explaining in more detail how color-managed printing will work using libCmpx. What’s important to know right now is that the dialog actually uses a simulated “printer”, which contains special driver attributes that handle the color-related options normally seen in print dialogs. (The choices that you see below Color Settings were actually obtained from the printer driver.)
Feel free to play around with it – it is included along with libCmpx. The instructions to build the library and the test dialog can be found here
The graphic that you see above is the architecture model for libCmpx – the key library used in getting printer color management to work in Krita. There is a slightly more detailed description on the ColourWiki page, but the entire library can be summarized as an application interface to calibrate printer settings (based on a selected ICC profile), as well as to generate a color-managed, print-ready PDF file.
With last week’s work of prepping the libCmpx code for development all finished, I will now proceed to fine-tune both libCmpx ‘Selector’ and ‘Renderer’ code. Both these modules – with the help of Ghostscript and Oyranos – actually do the work to make print color management happen. Of course, with the abstraction that was recently implemented in libCmpx, the Krita developer and user will not know about the kind of work they are doing inside the library. Such is the magic of abstraction!
In addition to the code updates, I’ve mostly been busy setting up the library’s test application. The “libCmpx Test Dialog” is a print dialog simulator that will be used for development work, making sure that the library is in good shape to be included into Krita. It is now housed in libCmpx git, but is not quite ready yet (it should be fixed by the end of the weekend).
Onward now to some serious coding…!
This is my first pre-GSoC update for the Krita color-managed printing project. Although the official start of Google Summer of Code is not until May 22, it is nevertheless a good idea to get the ball rolling early.
Last week I have been polishing up the libCmpx code and improving its color-management abstraction. The original prototype library (XCPD) lacked proper abstraction in its code, and was a little difficult to read and understand. The recent structure change in libCmpx should make things easier for me to work during the summer, as well as providing a cleaner interface for when the library is eventually implemented in Krita.
In a few more days, I will post on my blog and on ColourWiki an updated diagram of the libCmpx structure. In addition, I will begin creating a new test suite for libCmpx in order to make sure that the library is up to snuff prior to integration.
I will be picking up the pace in the coming weeks and will provide much more substantial updates – May 12 will be the first day that I am able to work full-time on the project.
The Krita printer color management proposal has been accepted into the 2012 Google Summer of Code!
The initial phase of this project will actually begin right now – it will involve fine-tuning the libCmpx interface, looking over the possible areas of integration in Krita, and formulating a game plan with my mentor and the key people involved with printing and color management. The official coding period begins in late May, so there is time at the moment to lay down a three-month strategy.
This project will be a huge undertaking for me, especially since color-managed printing under Linux is essentially on the cusp of becoming a reality. But I will do my best in the coming months!