Re: [OctDev] Re: [Octave-cvsupdate] octave-forge/main/image imread.m,1.11,1.12 imwrite.m,1.8,1.9

[Paul K. <pki...@us...>]

On Jul 27, 2005, at 10:56 PM, Andy Adler wrote:

> On 7/27/05, Paul Kienzle <pki...@us...> wrote:
>>
>> On Jul 26, 2005, at 3:57 AM, Stefan van der Walt wrote:
>>
>>> On Tue, Jul 26, 2005 at 12:06:14AM -0400, Andy Adler wrote:
>>>> Damn. libMagick API versions was a problem three years ago. I 
>>>> decided to
>>>> ignore them for a few years to hope they sorted themselves out. 
>>>> Looks like I'll
>>>> have to wait for another few years.
>>>
>>> I hoped that we could use libraries like libgd or libimlib, but these
>>> are all huge overkill.
>>
>> Can the additional features of these libraries be exposed to octave,
>> and maybe replace some of the other functions in the image processing
>> toolbox?
>
> For a general purpose image processing interface, the libMagick API
> is really the best. It transparently handles all image formats and 
> offers
> the ability to do lots of image processing operations. Unfortunately,
> different versions change significantly, so the code will be littered 
> with
> #ifdefs. This still may be the best solution. If imread depends on
> imagemagick binaries, then depending on the libraries should be OK.

Rather than peppering our code with #ifdef, I would suggest supporting 
the
latest API only and writing a translation layer to the older APIs.  Let
configure sort out whether the translation is included.  Maybe somebody
has already done so and gave it to the libMagick community?  Or are the
API's so incompatible that this won't work?

- Paul