From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2006-06-24 12:01:15
Janek Kozicki wrote:
> Stefan Seefeld said: (by the date of Sat, 24 Jun 2006 10:39:00 -0400)
>> Janek Kozicki wrote:
>>> Displaying images on the screen has nothing to do with image-handling
>>> That's what I would expect from image handling library (just few examples):
>>> - Changing image brightness,
>>> - adjusting gamma levels,
>>> - changing color modes,
>>> - converting from CMYK to YCbCr,
>>> - scaling using various interpolation methods,
>>> - rotating.
>>> - provide an access method for OTHERs who want to display the image on
>>> the screen (or somewhere else), it's not even the UI (or the printer)
>>> that displays this image - it is something in between.
>>> - etc..
>>> - Image I/O in various formats (tiff,jpg,png) is just an extra bonus here.
>> What about image *processing* ? Things like
>> - sharpening, smoothing, thresholding, dilation, erosion
>> - compression, FFTs, wavelets
>> - feature detection, segregation
>> - morphing
> I have only quickly skimmed through GIL docs, so I don't know if GIL
> provides *processing* algorithms. It would be nice to have that. But
> maybe due to the fact the the number of such *processing* methods is
> almost infinite (just look at how many plugins GIMP has) I rather expect
> this library to provide an easy interface to implement any (and all) of
> those that you mentioned above.
I agree. I didn't mean to suggest that all the above should be added to GIL
itself. Rather, my point was that there are many situations where images are
dealt with in a non-interactive (and, in particular, non-GUI) way.
-- ...ich hab' noch einen Koffer in Berlin...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk