help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Help with matrix replication


From: Richardson, Anthony
Subject: RE: Help with matrix replication
Date: Thu, 20 Dec 2012 21:04:38 +0000

> From: address@hidden [mailto:address@hidden On Behalf Of
> Subject: Re: Help with matrix replication
> On 20 December 2012 19:28, Richardson, Anthony <address@hidden>
> wrote:
> >> On Behalf Of Carnë Draug
> >> > Subject: Help with matrix replication
> >> >
> >> > By the way, imresize(a, 2, 'nearest') will do what I want, but this
> >> > is a
> >> function from the image package and I'm trying to write some routines
> >> that duplicate the functionality of the image package without using
> >> any of those functions.
> >>
> >> Why are you avoiding the image package? It's the second time this
> >> week someone tries to solve something that is already on a package
> >> but does not want to use it. I don't understand the aversion.
> >>
> >> You know that you can at least just look into imresize, see how it
> >> works and use it.
> >
> > I'm not averse to using it.  I'm using it a lot, but I'm also studying image
> processing and most of the study involves implementing many image
> processing algorithms in Octave.  Most (all?) of the algorithms are already
> implemented in the image package.  We aren't allowed to use routines from
> the image package except to compare the results from our routines to those
> from the image package.
> 
> Oh! Ok, so it's an assignment, I understand that.
> 
> > Also, imresize appears to fit the image matrix to a grid and then uses
> > one of several different interpolation methods (user selectable) to
> > generate a new (larger or smaller) image matrix.  I'm interested only
> > in the specific case of generating a larger matrix by pixel
> > replication (at this point) and thought that clever indexing might
> > provide a "better" solution than the more general interpolation method
> > used by imresize.  That appears to be the case.  On my machine
> > resizing a 2x3 double matrix by a factor of 1000 using indexing is
> > over 50 times faster than using imresize.  Also, I can increase the
> > same matrix by a factor of 5000 using indexing, but get a "memory
> > exhausted" error when using imresize with a factor of 2000.  (I'm not
> > complaining about imresize.  It is great, but it might not be the best
> > method to use when you are interested only in pixel replication.)
> 
> It's perfectly acceptable to have imresize use different methods for different
> cases. It doesn't need to have a single solution, whatever is faster is 
> better.
> Would you be able to supply a patch for us?
> 
> Carnë

Pixel replication appears to produce the same result as imresize only when 
imresize is used with the "nearest" interpolation option and only for integer 
scale factors greater than one.  (imresize supports non-integer scale factors 
both larger (enlarge) and smaller (shrink) than one.)

Anyway:

  b = a((1:size(a,1))(ones(1,n),:), (1:size(a,2))(ones(1,n),:));

appears (for the test cases I've run) to return the same result as b = 
imresize(a, n, 'nearest') when n is an integer larger than one.  In this 
particular case, the line above is much faster and uses much less memory than 
imresize.

Similarly, I assume pixel elimination:

m = round(1/n);
b = a(1:m:end,1:m:end);

would be faster than b = imresize(a, n) when (1/n) is an integer greater than 
one (image shrinking) regardless of the interpolation method (but I have not 
tested this).

I don't know that such special cases (enlarging or shrinking by integer scale 
factors) merit making changes to imresize.

Tony


reply via email to

[Prev in Thread] Current Thread [Next in Thread]