Skip to content

Boost.GIL 3 Ideas

Jump to bottom Edit New page
Mateusz Łoskot edited this page Apr 3, 2020 · 26 revisions

Status

  • Draft under heavy brainstorm
  • Accepted ideas are submitted as issues/PRs to Boost.GIL 3 project.

Modern C++

  • Good outline of the C++11 Metaprogramming by Peter Dimov - Part 1 and Part 2
  • Use Boost.Hana for metaprogramming, defining types like pixel, color spaces, etc.
  • C++11: delegating constructor
  • C++11: move semantics constructor (#438 and PR #457)
  • using variadic templates will help
  • make use of overlapping functionality with boost::geometry, like point type registration. See Andrew Hundt's email from 2013/03/13
  • pixel should have a begin() and end() members.
  • make Alignment a template parameter for image class
  • use boost::fusion for defining pixel and color spaces. See emails

Library structure

Boost.GIL 3 Documentation

  • Structure (prose, API reference)

Tutorials

Interesting Q&A on Boost mailing list, StackOverflow and other places as candidates for tutorials:

Performance

  • Use OpenCV as backend?

New type for subsampled image

  • image class has a boolean template parameter defining wheather or not an image is planar.
  • view_t is defined with view_type_from_pixel
  • if planar == true then special allocate_( ... )

Extension: IO

Add support for low level image libs

Designing a JPEG Decoder & Source Code

Raw format

Understanding What is stored in a Canon RAW .CR2 file, How and Why

Windows natives support

GDAL support

JPEG XR support

BPG support

This is a curious format, could be interesting, for comparative tests, etc.

Others

Algorithms

Interoperability with similar libraries

http://developers.slashdot.org/story/14/01/04/2115249/cairo-2d-graphics-may-become-part-of-iso-c

Extension: Color Management

Lea Verou writes: To accurately convert values from RGB to CMYK and vice versa, the way Photoshop does, you need to use an ICC color profile. All the simple algorithmic solutions you'll find in the interwebs (like the one posted above) are inacurrate and produce colors that are outside the CMYK color gamut (for example they convert CMYK(100, 0, 0, 0) to rgb(0, 255, 255) which is obviously wrong since rgb(0, 255, 255) can't be reproduced with CMYK). Look into the java.awt.color.ICC_ColorSpace and java.awt.color.ICC_Profile classes for converting colors using ICC color profiles. As for the color profile files themselves, Adobe distributes them for free. (http://stackoverflow.com/questions/4858131/rgb-to-cmyk-and-back-algorithm)

@vinniefalco writes: There is not a 1:1 relationship between "converting" from RGB to CMYK. In fact there are an infinite number of ways to represent an RGB image as a CMYK image, by varying the amount of black and using different algorithms (undercover removal or gray component replacement for example). Not all representations match the original RGB image, as the gamut of CMYK is typically smaller than the gamut of RGB. The process of turning an RGB image into a CYMK image is called "color separation", and algorithms to do this are very valuable and of course totally proprietary. There is also another important and related process, which is to render a CMYK image as an RGB image using proper colors. In order to do this, you generally need to know:

  • The precise CIE XYZ color values for each of the inks (Cyan, Magenta, Yellow, and Black)
  • Metadata about the ink+paper, for example the dot spread, and the paper's white color
  • The color profile of the RGB monitor, this is used to convert perceptual CIE XYZ colors into color-correct RGB colors (this transformation is particular to the monitor's color profile)

A scientist by the name of Hans E. J. Neugebauer published a paper in 1937 ("Die theoretischen Grundlagen des Mehrfarbenbuchdrucks", or "The theoretical foundations of multicolor printing") which proposed a model for predicting the CIE XYZ color that a given CMYK halftoned pattern might look like. These are known as the "Neugebauer Equations." All modern programs (such as Photoshop) use some variation of these Neugebauer equations, with improvements to make the model more accurate. Some of these improvements can be seen in published papers (some not). Using these equations, one can predict the CIE XYZ color of a CMYK dot given information about the inks and paper. This can then be used to display the CMYK image in a colorimetrically correct fashion using the monitor's color profile as described above. This algorithm is called "Proof Colors" in Photoshop.

An implementation of Proof Colors (CMYK to color-correct RGB) by definition will have a formula for mapping CMYK to RGB. If this mapping were inverted, it can be used to perform a color separation (converting perceptual RGB to CMYK for a given set of inks and paper). Unfortunately, there is a wrinkle here. While the CMYK to RGB algorithm is one to one, the inverse is not. As stated earlier, there are an infinite number of CMYK images which in theory will all look like the same RGB image. To choose between these possibilities, the algorithm must be given guidance such as the amount of black to use and the manner in which colors are substituted (undercolor removal, gray component replacement). There is also another wrinkle, which is that the Neugebauer equations are not analytically invertible. This inversion will have to be performed numerically using an iterative algorithm such as Newton's method.

book http://www.amazon.com/Color-Management-Understanding-Profiles-Technology/dp/0470058250/ref=sr_1_1?ie=UTF8&qid=1360260936&tag=fithfi-20

web resources: http://www.color.org/faqs.xalter http://en.wikipedia.org/wiki/ICC_profile

implementations https://docs.oracle.com/javase/7/docs/api/java/awt/color/ICC_ColorSpace.html

Better YUV

http://en.wikipedia.org/wiki/Common_Intermediate_Format

Some Links:

integration with dmilos/color library

https://github.com/dmilos/color - implements color conversion and manipulation.

Old bag

These ideas are old and might be obsolete.

Add a custom footer
Add a custom sidebar
Clone this wiki locally