Re: [boost] GIL - Generic Image Library Review - Begins October 5

From: Lubomir Bourdev (lbourdev_at_[hidden])
Date: 2006-10-11 18:50:39

Andy Little wrote:
> - What is your evaluation of the design?
> 
> I believe that the various Concepts namely treating a data sequence as
a
> view on
> a matrix or grid, iterating a matrix or Grid , and Color have not been
> adequately thought about in their own right.

We have discussed our disagreements on separating out Color and Grid in
separate lengthy emails. To summarize my points:

For Color: Though the idea is appealing, you cannot deal with color in
an abstract way; in a color library you must account for how color is
represented in memory. There are a large number of representations out
there (order of channels, channel depth, subbyte representation, etc.)
Where do all these representations come from? Almost exclusively they
come from the way colors in _images_ are represented. So all these
memory representations are specific to images and therefore logically
they must be supported inside an image library. This explains why color
is inside every image library I have looked at.

For Grid: Again, what concrete example can you give me that requires
GIL-s generalization of a Grid and cannot be represented as an image.
Your example of a DisplayMatrix for text characters quickly falls apart.
If you need a generic grid navigation, why not use a library whose goal
is more aligned to grids and navigation, such as boost::MultiArray? 

> 
>  - What is your evaluation of the implementation?
> 
> I didnt look in detail. It appeared that some typedefs were only there
to
> meet
> GIL Concept requirements and appeared to be unused. This is an
indication
> that
> the implementation probably has unneccessary dependencies.

There are typedefs that are required by N-dimensional concepts, for
example get an iterator over the N-th dimension of a locator/view/image.
These are important so that current 2D models can be used in future
generic N-dimensional algorithms.

>  - What is your evaluation of the documentation?
> 
> Links to the Concepts don't work (they point to local files on my
system).

Yes, after you brought it up, I discovered that the PDF files have dead
links. In the future we will remove the links when generating the PDFs.
The HTML links should be working properly.

> The use of ConceptC++ style concepts is problematic. My suggestion is
that
> if
> one wishes to use this style in the Docs then you should also follow
> through and
> actually put the Concepts into code and compile them on ConceptGCC.
You
> could
> then verify that the documentation is correct. I suspect that the
current
> GIL
> docs would require a lot of work to pass that test. In fact I would
make
> that a
> requirement for any Docs that wish to use the ConceptGCC format.
> This would be an interesting discipline and I suspect would result in
> design
> changes to the library itself.

Compiling GIL on ConceptGCC is a great idea and we will do so. Where can
we get ConceptGCC from?
Had you looked in the code though, you would have discovered that GIL
concepts have associated Concept classes, and yes, GIL compiles
successfully with boost::concept_check enabled. While this is probably
not as strict as ConceptGCC, it suggests that large changes to the
library are unlikely.

> There is a format (official or unofficial) for library reviews, which
has
> not
> been followed. The code is designed to be copied into the reviewers
boost
> distribution for evaluation. 

Given that some other libraries have used external links as well, my
understanding is that the vault is for convenience to developers that
don't have an easy way to distribute their library. I believe our web
page has an easy way to get to the code and documentation and may be
more convenient to navigate than a directory of files.

> The installations section of the tutorial
> doesnt
> cover quite what you are meant to do to install the library.

The tutorial refers you to GIL's web page which contains detailed
installation instructions.

> 
> Suggestions for a first example. Load an image, provide some means or
> suggestions so that you can view the image. Show code for a transform
of
> the
> image. View the result. Proceed like that. 

Have you looked at slide 88 of the video presentation? It is doing
exactly this. It shows GIL code to the left and the result to the right.
Having a GUI to display an image in a platform independent way is beyond
the scope of the library, as we have discussed in an earlier thread. You
can just save the image and use your favorite image viewer.

Lubomir