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

From: Andy Little (andy_at_[hidden])
Date: 2006-10-12 03:56:51

"Lubomir Bourdev" <lbourdev_at_[hidden]> wrote in message
news:B55F4112A7B48C44AF51E442990015C0016B74D0_at_namail1.corp.adobe.com...
> 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.

I think I have covered this in other posts.

> 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?

The Concept of grid navigation is interesting and I like the locator in GIL.

Boost.MultiArray is a model of a grid sure.

The example that interests me is the mandelbrot example. The mandelbrot function
itself is a poor demo because generating points is nearly random, but  here
there is no actual grid in required to be in memory, but there is still the
concept of a grid..  All that is required is the clipping region (You could have
a grid in memory to cache the results of previous views if the user is moving
about, but it is not required). The locator  ( I would call it cursor) maybe
provides the ability to iterate over a non-existent grid, which appeals to me.
dereferencing the cursor where some elements are functions and others are data
elements and things could get interesting. An obvious application for a bitmap
is where many pixels are the same colour. One could also provide a function
which allows the cursor to navigate the grid maybe following an edge ( a
significant difference between two neigbouring elements maybe) and recording its
path for example.

>>  - 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.

ConceptC++ is a different animal. My limited experience with it so far has been
to throw away most ideas regarding templates. Porting a libary to ConceptC++
will be AFAICS, a major project.

>> 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.

As regards the way the review material is packaged for potential reviewers, I
think you could revisit it ;-)

regards
Andy Little