Thread: [OctDev] jpgread changed

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

testimio is now failing because the output of jpgread has changed.

Should we maintain support for [r,g,b]=jpgread... instead of forcing an 
nxmx3 matrix im=jpgread?

- Paul

On 10/4/05, Paul Kienzle <pki...@us...> wrote:
> testimio is now failing because the output of jpgread has changed.
>
> Should we maintain support for [r,g,b]=3Djpgread... instead of forcing an
> nxmx3 matrix im=3Djpgread?

jpgread was never officially part of Matlab AFAIK (a version was posted
by someone to comp.soft-sys.matlab in the early 90's). Thus we are
not breaking compatibility either way.

OTOH, imread has not given [r,g,b] output since version 5.

Andy

On Oct 5, 2005, at 5:28 PM, Andy Adler wrote:

> On 10/4/05, Paul Kienzle <pki...@us...> wrote:
>> testimio is now failing because the output of jpgread has changed.
>>
>> Should we maintain support for [r,g,b]=jpgread... instead of forcing 
>> an nxmx3 matrix im=jpgread?
>
> jpgread was never officially part of Matlab AFAIK (a version was 
> posted by someone to comp.soft-sys.matlab in the early 90's). Thus we 
> are not breaking compatibility either way.
>
> OTOH, imread has not given [r,g,b] output since version 5.
>

Regardless, is it of value to the users of the image routines to be 
able to read directly into [r,g,b]?

If the answer is no, then someone needs to change testimio.

- Paul

On 10/6/05, Paul Kienzle <pki...@us...> wrote:
> On Oct 5, 2005, at 5:28 PM, Andy Adler wrote:
> > On 10/4/05, Paul Kienzle <pki...@us...> wrote:
> >> Should we maintain support for [r,g,b]=3Djpgread... instead of forcing
> >> an nxmx3 matrix im=3Djpgread?
> >
> > jpgread was never officially part of Matlab AFAIK (a version was
> > posted by someone to comp.soft-sys.matlab in the early 90's). Thus we
> > are not breaking compatibility either way.
> >
> > OTOH, imread has not given [r,g,b] output since version 5.

I have a rewrite of imread as an oct-file binding to libmagick++ in
the works. AFAIK Imagemagick supports all of the formats of the
current imread implementation or more and I found that reading some
formats to octave is 2 orders of magnitude faster with imagemagick.

I plan to support the imread interface documented at the Mathworks
website as much as possible.

Teemu

On Wed, Oct 12, 2005 at 07:32:23PM +0300, Teemu Ikonen wrote:
> I have a rewrite of imread as an oct-file binding to libmagick++ in
> the works. AFAIK Imagemagick supports all of the formats of the
> current imread implementation or more and I found that reading some
> formats to octave is 2 orders of magnitude faster with imagemagick.

Is the libmagick++ API stable?  We experimented with it a while ago,
and had problems over different versions.

The current implementation of imread calls jpgread and pngread when
appropriate, so loading png and jpegs should be (almost) as fast as
when using libmagick.  ImageMagick requires libpng and libjpeg, but I
guess it would be safer to depend on their implementation.

What I don't like about that solution is that we'll be needing a lot
of extra development headers, many of which we'll never use.  So we
should probably look into making use of more ImageMagick functionality
in other parts of the image toolbox as well.

Regards
St=E9fan

On 10/12/05, Teemu Ikonen <tpi...@pc...> wrote:
> I have a rewrite of imread as an oct-file binding to libmagick++ in
> the works. AFAIK Imagemagick supports all of the formats of the
> current imread implementation or more and I found that reading some
> formats to octave is 2 orders of magnitude faster with imagemagick.
>
> I plan to support the imread interface documented at the Mathworks
> website as much as possible.

This is a great idea. I did not do this in the past because the libMagick++
API was not stable. Maybe it is now.

Imagemagick also implements lots of other algorithms. Maybe there
can be a generic way to access these api features.

Andy

On 10/12/05, Stefan van der Walt <st...@su...> wrote:
> On Wed, Oct 12, 2005 at 07:32:23PM +0300, Teemu Ikonen wrote:
> > I have a rewrite of imread as an oct-file binding to libmagick++ in
> > the works. AFAIK Imagemagick supports all of the formats of the
> > current imread implementation or more and I found that reading some
> > formats to octave is 2 orders of magnitude faster with imagemagick.
> Is the libmagick++ API stable?  We experimented with it a while ago,
> and had problems over different versions.

I have no idea about the stability of the API, other than that Debian
seems to be having some sort of library transition going on with it at
the moment.

> What I don't like about that solution is that we'll be needing a lot
> of extra development headers, many of which we'll never use.  So we
> should probably look into making use of more ImageMagick functionality
> in other parts of the image toolbox as well.

We will have to use the library dependencies if we want to support
loading of large number of formats and IMHO we should. The solution to
octave-forge having dependencies to half of the world is to devise a
decent module system to Octave and split octave-forge to smaller
pieces.

Teemu

Thread: [OctDev] jpgread changed

A collection of packages providing extra functionality for GNU Octave

octave-dev