[OctDev] jpgread changed

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[OctDev] jpgread changed

Paul Kienzle-3
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



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Octave-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev
Reply | Threaded
Open this post in threaded view
|

Re: [OctDev] jpgread changed

Andy Adler-8
On 10/4/05, Paul Kienzle <[hidden email]> 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.

Andy


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Octave-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev
Reply | Threaded
Open this post in threaded view
|

Re: [OctDev] jpgread changed

Paul Kienzle-3

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

> On 10/4/05, Paul Kienzle <[hidden email]> 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



-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Octave-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev
Reply | Threaded
Open this post in threaded view
|

Re: [OctDev] jpgread changed

Teemu Ikonen
On 10/6/05, Paul Kienzle <[hidden email]> wrote:

> On Oct 5, 2005, at 5:28 PM, Andy Adler wrote:
> > On 10/4/05, Paul Kienzle <[hidden email]> wrote:
> >> 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.

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


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Octave-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev
Reply | Threaded
Open this post in threaded view
|

Re: [OctDev] jpgread changed

Andy Adler-3
On 10/12/05, Teemu Ikonen <[hidden email]> 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


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Octave-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev
Reply | Threaded
Open this post in threaded view
|

Re: [OctDev] jpgread changed

Stéfan van der Walt
In reply to this post by Teemu Ikonen
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éfan


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Octave-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev
Reply | Threaded
Open this post in threaded view
|

[OctDev] jpgread changed

Teemu Ikonen
On 10/12/05, Stefan van der Walt <[hidden email]> 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


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Octave-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/octave-dev