Octave Forge

St=E9fan,

That sounds like a good idea. On the other hand, a better implementation
would be to write an oct file  to link to the imagemagick libraries directl=
y.

After that, the only reason to have jpgread etc is for users that don't hav=
e
libmagick.a.

What do you think?

Andy

On 7/24/05, Stefan van der Walt <stefan@...> wrote:
> Last time I checked, the pipes implementation was much slower than the
> file approach for large images.  Can you verify whether this is still
> the case?
>=20
> I have made some fixes to pngread and jpegread, which I will submit
> soon.  Then, we can use those functions in imread.m to load JPGs and
> PNGs, but revert to ImageMagick otherwise.
>=20
> Regards
> St=E9fan
>=20
> On Thu, Jul 21, 2005 at 04:03:08PM +0000, andy adler wrote:
> > Update of /cvsroot/octave/octave-forge/main/image
> > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22457/main/image
> >
> > Modified Files:
> >       imread.m imwrite.m
> > Log Message:
> > Improve error messages and use pipes
> >
> > Index: imread.m
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > RCS file: /cvsroot/octave/octave-forge/main/image/imread.m,v
> > retrieving revision 1.11
> > retrieving revision 1.12
> > diff -u -d -r1.11 -r1.12
>

ImageMagick unfortunately also links to libjpeg and libpng to read
those two formats.  Also, the libMagick API has changed from version 6
to 8 -- some distributions like Debian keep to v6 while others like
Mandrake have moved to v8.

Whichever way, the API example given on their webpage compiles but
doesn't run with either versions!

St=E9fan

On Sun, Jul 24, 2005 at 08:24:11AM -0400, Andy Adler wrote:
> St=E9fan,
>=20
> That sounds like a good idea. On the other hand, a better implementatio=
n
> would be to write an oct file  to link to the imagemagick libraries dir=
ectly.
>=20
> After that, the only reason to have jpgread etc is for users that don't=
 have
> libmagick.a.
>=20
> What do you think?
>=20
> Andy
>=20
> On 7/24/05, Stefan van der Walt <stefan@...> wrote:
> > Last time I checked, the pipes implementation was much slower than th=
e
> > file approach for large images.  Can you verify whether this is still
> > the case?
> >=20
> > I have made some fixes to pngread and jpegread, which I will submit
> > soon.  Then, we can use those functions in imread.m to load JPGs and
> > PNGs, but revert to ImageMagick otherwise.
> >=20
> > Regards
> > St=E9fan

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.

For now, I'll modify imread to use jpgread/pngread. Tell me when you've
committed your modifications.

Andy

On 7/25/05, Stefan van der Walt <stefan@...> wrote:
> ImageMagick unfortunately also links to libjpeg and libpng to read
> those two formats.  Also, the libMagick API has changed from version 6
> to 8 -- some distributions like Debian keep to v6 while others like
> Mandrake have moved to v8.
>=20
> Whichever way, the API example given on their webpage compiles but
> doesn't run with either versions!
>=20
> St=E9fan
>=20
> On Sun, Jul 24, 2005 at 08:24:11AM -0400, Andy Adler wrote:
> > St=E9fan,
> >
> > That sounds like a good idea. On the other hand, a better implementatio=
n
> > would be to write an oct file  to link to the imagemagick libraries dir=
ectly.
> >
> > After that, the only reason to have jpgread etc is for users that don't=
 have
> > libmagick.a.
> >
> > What do you think?
> >
> > Andy
> >
> > On 7/24/05, Stefan van der Walt <stefan@...> wrote:
> > > Last time I checked, the pipes implementation was much slower than th=
e
> > > file approach for large images.  Can you verify whether this is still
> > > the case?
> > >
> > > I have made some fixes to pngread and jpegread, which I will submit
> > > soon.  Then, we can use those functions in imread.m to load JPGs and
> > > PNGs, but revert to ImageMagick otherwise.
> > >
> > > Regards
> > > St=E9fan
>

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 t=
o
> ignore them for a few years to hope they sorted themselves out. Looks l=
ike 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.

> For now, I'll modify imread to use jpgread/pngread. Tell me when you've
> committed your modifications.

Please see the attached imread2.m, pngread.cc etc.

The only thing to note about these is that they already return colour
images in the MxNx3 format.  Octave 2.9 branch supports showing these,
but many other functions don't (yet).  I don't think this should be a
problem if I provide an im2gray function, though.

'imread2' also makes use of files instead of pipes, since those
are rather slow.  The ImageMagick 'identify' utility is used to decide
on the image depth.

Regards
St=E9fan

On 7/26/05, Stefan van der Walt <stefan@...> wrote:
> Please see the attached imread2.m, pngread.cc etc.
>=20
> The only thing to note about these is that they already return colour
> images in the MxNx3 format.  Octave 2.9 branch supports showing these,
> but many other functions don't (yet).  I don't think this should be a
> problem if I provide an im2gray function, though.

In my opinion, you should commit these. Imread2 should replace
imread. As we move to Octave 3.0, now is the time to clean out cruft
like imread returning parameters compatible with matlab 4.

Do any others have opinions on this?

Andy

Andy Adler wrote:
(snip)
> In my opinion, you should commit these. Imread2 should replace
> imread. As we move to Octave 3.0, now is the time to clean out cruft
> like imread returning parameters compatible with matlab 4.
>=20
> Do any others have opinions on this?
I couldn't agree more. One of the great things about major releases is=20
that the old "garbage" can be thrown out.

> Andy
/S=F8ren

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?

- Paul

On Jul 26, 2005, at 9:43 PM, Andy Adler wrote:

> On 7/26/05, Stefan van der Walt <stefan@...> wrote:
>> Please see the attached imread2.m, pngread.cc etc.
>>
>> The only thing to note about these is that they already return colour
>> images in the MxNx3 format.  Octave 2.9 branch supports showing these,
>> but many other functions don't (yet).  I don't think this should be a
>> problem if I provide an im2gray function, though.
>
> In my opinion, you should commit these. Imread2 should replace
> imread. As we move to Octave 3.0, now is the time to clean out cruft
> like imread returning parameters compatible with matlab 4.
>
> Do any others have opinions on this?

It would be nice to support old and new versions of Matlab's 
ever-changing API so that as much as possible code just works.  
However, with nobody willing do do the work, I agree that dropping the 
Matlab 4 support is the best path forward.  Someday somebody who cares 
can implement a v4 wrapper on functions which have changed.

- Paul

On 7/27/05, Paul Kienzle <pkienzle@...> wrote:
>=20
> On Jul 26, 2005, at 3:57 AM, Stefan van der Walt wrote:
>=20
> > 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.
>=20
> 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,=20
different versions change significantly, so the code will be littered with
#ifdefs. This still may be the best solution. If imread depends on=20
imagemagick binaries, then depending on the libraries should be OK.

Andy

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

> On 7/27/05, Paul Kienzle <pkienzle@...> 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

On Thu, Jul 28, 2005 at 07:32:03AM -0400, Paul Kienzle wrote:
>=20
> Rather than peppering our code with #ifdef, I would suggest supporting=20
> 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?

Maybe the higher-level libMagick++ doesn't suffer from these
problems.  I'll take a look.

Regards
St=E9fan