Re: [boost] GIL - late review

From: Hans Meine (meine_at_[hidden])
Date: 2006-11-13 08:59:59

Hi again!

On Tuesday, 07. November 2006 01:58, Lubomir Bourdev wrote:
> My rule of thumb: when I provide functionality that is similar but not
> identical to existing functionality, I go out of my way to indicate that
> they are different. This is why GIL calls 2D 'iterators' locators,
> although they are almost identical to traditional iterators.
For the same reason, they're called traversers in VIGRA nowadays.
(Actually, I prefer traverser vs. locator - doesn't the latter imply some kind 
of searching?)

> Similarly, 
> I prefer names like resize_and_clobber(), resize_and_invalidate(),
> create_with_new_dimensions(), recreate(), or reset() than resize(). What
> do other people think?
What about reshape()?

> > > Right now GIL hard-codes the commonly used types to their
> >
> > commonly used
> >
> > > ranges -  float is 0..1.
> >
> > Really? I didn't realize this and don't like it at all as a default
> > setting. IMHO, the pleasant property of floats is that one (mostly)
> > doesn't need to take care of ranges and loss of precision.
>
> Think of these as part of the channel traits specifying the legal range
> of the channel, which is often smaller than its physical range. You are,
> of course, free to ignore them (and it may make sense to do so in
> intermediate computations), but they are implicitly always defined.
> Having them explicitly defined makes certain operations much easier,
> such as converting from one channel type to another. Not having them
> defined would force you to propagate them to every function that might
> need them.
In VIGRA, a
  copyImage(srcImageRange(my8bitImage), destImage(some16bitOrFloatImage))
will simply copy the values without any linear transformation.
This looks to me like the principle of least surprise.  If GIL transforms byte 
ranges 0..255 to float 0.f..1.f, will it also shift by 8 bits for 8->16 bit 
conversions?

When discussing the stacking of views, your argument was:
> I am in favor of letting the programmer choose what is best rather than
> imposing one strategy, which in my opinion is the style of C++ and STL
> as compared to other languages.

Does this argument not hold for the above case?

> For example channel_convert will need to be provided the minimum and
> maximum value for both source and destination, and so will the color
> conversion functions, the color converted view, etc.

I don't think so - I would imagine a linear_transformation or linear_scaling 
view, which could be used explicitly in case the domain shall be changed.

Greetings,
  Hans