Menu
▾
▴
octave-dev
|
From: Stefan v. d. W. <st...@su...> - 2005-07-24 10:02:18
|
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? 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 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 >=20 > Modified Files: > imread.m imwrite.m=20 > Log Message: > Improve error messages and use pipes >=20 > 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 |
|
From: Andy A. <ax...@gm...> - 2005-07-24 12:24:53
|
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 <st...@su...> 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 > |
|
From: Stefan v. d. W. <st...@su...> - 2005-07-25 09:20:32
|
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 <st...@su...> 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 |
|
From: Andy A. <ax...@gm...> - 2005-07-26 04:06:26
|
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 <st...@su...> 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 <st...@su...> 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 > |
|
From: Stefan v. d. W. <st...@su...> - 2005-07-26 07:58:53
|
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 |
|
From: Andy A. <ax...@gm...> - 2005-07-27 01:43:59
|
On 7/26/05, Stefan van der Walt <st...@su...> 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 |
|
From: <so...@ha...> - 2005-07-27 07:26:02
|
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 |
|
From: Paul K. <pki...@us...> - 2005-07-27 11:44:33
|
On Jul 26, 2005, at 9:43 PM, Andy Adler wrote: > On 7/26/05, Stefan van der Walt <st...@su...> 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 |
|
From: Paul K. <pki...@us...> - 2005-07-27 11:38:54
|
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 |
|
From: Andy A. <ax...@gm...> - 2005-07-28 02:56:58
|
On 7/27/05, Paul Kienzle <pki...@us...> 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 |
|
From: Paul K. <pki...@us...> - 2005-07-28 11:32:13
|
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 |
|
From: Stefan v. d. W. <st...@su...> - 2005-07-28 13:55:45
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X