Boost.GIL IO and Toolbox extensions accepted into Boost

I have just announced results of the formal review of IO and Toolbox extensions for Boost Generic Image Library (GIL). Shortly, formally, the review concluded with 1 NO and 7 YES votes what means both extensions have been accepted into Boost C++ Libraries.

The task has been finished, but the mission is still ongoing. Lubomir Bourdev (Adobe) – Boost.GIL lead developer summarised it quite well:

The problem with I/O is that you can never declare success.
All we can hope for is push the boundary as much as we can, and leave the rest for the next update.

Christian Henning has done great job developing the extensions and reviewers confirmed it. It was pleasure for me to manage the review process.

Formal Review of IO and Toolbox extensions to Boost.GIL starts TOMORROW

I am honoured to act as a Boost Review Manager for the proposed Boost.GIL.IO and Boost.GIL.Toolbox extensions. Today, I announced the review starting tomorrow:

According to the Boost Formal Review Schedule, review of Christian Henning’s extensions to the Boost Generic Image Library (Boost.GIL), it is:

  • Boost.GIL.IO
  • Boost.GIL.Toolbox

starts on December 1st and lasts until December 10th, 2010.

What is it?

The Boost.GIL.IO extension provides an easy to use interface for reading and writing various image formats. It also includes a framework for adding new formats. The Boost.GIL.IO is indent to replace the current IO extension which is part of Boost for several years now.

  • A unified way to read and write image encoded in BMP, JPEG, PNG, PNM and TIFF formats. The capabilities to read and write in various formats have improved dramatically.
  • Image data can be provided via standard file or string streams.
  • The Boost.GIL.Toolbox provides new color spaces and other small code to ease programming with Boost.GIL.

  • Implementation of color spaces: Gray_Alpha, HSL, HSV, LAB, and XYZ.
  • Utilities to support dynamic image workflows and color conversions.
  • Collection of metafunctions to determine alignment, similarity and homogeneity at pixel level.

The Boost.GIL as well as the proposed extensions are provided in form of a headers-only library Although, some image formats come with their format dependency, it is corresponding third-party libraries:

Getting the library

The latest version of both extensions can be downloaded as boost_review.zip package or directly from the Subversion repository. The docs can built as usual with bjam and quickbook tools from within libs/gil/io_new/doc directory. The libs/gil/io_new/test/readme.txt provides a step by step guide to configuring, building and running the unit tests. (By the way, here are some more details on how we’ve managed to get the Boost.GIL tests building with Boost.Build and Boost.Build extensions

The boost_review.zip is about 20MB due to its extensive collection of test images. They are part of the test suite to make sure that different variations of each image format is read and written correctly. Please, be aware no guarantee can be given that all formats in their all variants are completely supported.

Writing a review

If you feel the new IO and Toolbox are interesting extensions to the Boost.GIL library, then please submit your review to the developer list (preferably), or to the review manager.

Here are some questions you might want to answer in your review:

  • What is your evaluation of the design?
  • What is your evaluation of the implementation?
  • What is your evaluation of the documentation?
  • What is your evaluation of the potential usefulness of the extensions?
  • Did you try to use the extensions? With what compiler? Did you have any problems?
  • How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
  • Are you knowledgeable about the problem domain?
  • And finally, every review should answer this question:

  • Do you think the extensions should be accepted as a part of Boost.GIL library?
  • Be sure to say this explicitly so that your other comments don’t obscure your overall opinion.

Updating Boost.Build extensions

I’ve been continuing my Boost.Build adventures leading to preparation for review of the new Boost.GIL I/O framework. Here is a short patch with update I had to applie to Boost.Build extensions scripts for the libraries: jpeg-8a, libtiff 3.9.4 and zlib 1.2.4. It is boost-build_extensions-r66346-update.patch

This patch allowed me to successfully compile Boost.GIL tests. It’s been posted to the Boost mailing list, so perhaps it will be integrated with boost_extensions in the Boost Sandbox repository.

WKT Raster crash course #1

Recently, a good friend of mine Sandro has started spreading the story of WKT Raster project. Here, I’d like to join him and post a bunch of technical notes about how to start using tandem of PostGIS and WKT Raster. This is the first post that hopefully will start a series discussing various aspects of use and development of WKT Raster extension.

What

From the overview of WKT Raster project:

WKT Raster is an ongoing project aiming at developing raster support in PostGIS. (…) WKT Raster’s goal is to implement the RASTER type as much as possible like the GEOMETRY type is implemented in PostGIS and to offer a single set of overlay SQL functions (like ST_Intersects) operating seamlessly on vector and raster coverages.

The idea of WKT Raster extension was presented (PDF 1.1 MB) in December 2008 by Pierre Racine from University Laval. Pierre’s presentation made foundation of the WKT Raster Specification.

Hacker #1: Why WKTRaster? sounds a bit silly :D
Hacker #2: Apparently the initial thoughts on it were expressed using a textual representation for the rasters and the thinking was that this would be core to the effort, though it has proven not so important. I also find the name unhelpful.

Actually, this is not as trivial problem as it may seem. I am not sure myself that the name is WKT Raster or WKTRaster, nor I’m confident if the name is fixed and will be valid in future.

Update 2009-03-08 14:05: See Pierre’s comment below.

Where

At the moment, WKT Raster project does not have a single home, but different parts of it live in different places:

Who

Currently, there is a small team of people who contribute their time, skills and money to move the project forward. Here is a summary of contributors everyone can collect from the scattered homepage(s) of WKT Raster:

  • Pierre Racine – originator and author of the WKT Raster idea and specification and implementation developer.
  • Sandro Santilli – well-known member of the PostGIS core team who is the architect of RASTER type definition, canonical and Well-Known-Binary format of stored raster, developer of input/output operations, and more.

There are also prime financial contributors who established development of the WKT Raster project: Steve Cumming, Martin Daly (from Cadcorp, where I work as member of core development team) and Tyler Erickson.

Recently, I’ve also joined the WKT Raster team and being led by Martin Daly I’m focused on programming new features and core testing.

News

Today and during next 3 days, a few people interested in the PostGIS / WKT Raster project are meeting together for the Toronto Code Sprint 2009. I’m also present there, though in spirit by joining the event on #tosprint IRC channel. I have a hope that during this meeting, we will discuss and agree about a couple of outstanding issues:

  • meta data tables: Do we need them? How to define schema of meta data?
  • review of specification of RT functions
  • improvements in the solution architecture and design to handle common raster use cases, for both categories, visualizations and analysis
  • how to answer needs of pyramids/overviews
  • does the project need an infrastructure, a new home?
  • and last but not least, how to achieve sustainability and rise more funds.

By the way, isn’t it good time to create WKT Raster article on Wikipedia? Writers are welcome!