Re: TIFF Image Support Project GSOC

[Carnë Draug]

On Sun, 28 Mar 2021 at 12:00, Markus Mützel <markus.muetzel@gmx.de> wrote:
> Am 25. März 2021 um 19:01 Uhr schrieb "Carnë Draug":
> > On Wed, Mar 24, 2021 at 11:30 PM Nicholas Jankowski <jankowskin@asme.org> 
> > wrote:
> > > [...]
> > > @David - are there any similar existing wrappers/class
> > > implementations worth pointing out in particular as a reference?
> >
> > Not really.  The closest thing is the @ftp class which uses the old
> > style classes.  Its methods are pretty much single lines that simply
> > call the corresponding __dunder__ method.
>
> A few months back I started implementing a classdef wrapper for
> RapidXML that also follows a similar approach as the old-style @ftp
> class.
> See: https://savannah.gnu.org/bugs/index.php?59245
>
> I don't remember in which state it currently is. But I believe it
> was working more or less.  That implementation also aimed to achieve
> some compatibility with Matlab's XML interface. IIUC, that isn't an
> issue for this project because the libtiff wrapper would be internal
> to Octave.

Actually, the libtiff wrapper is supposed to implement the Tiff class
which exists in Matlab and is missing in Octave.  So yeah, Matlab
compatibility is required.  Having imread/imwrite/imfinfo make use
that Tiff class is something to do after.

This whole having multiple __dunder__ functions which are then called
from almost single line m files seems a bit silly.  I think it would
be cleaner to do it all in C++.  Is there a way to add a class to
Octave from an oct file only?