octave-dev — GNU Octave developers' list

Re: [OctDev] imrotate

[Justus P. <Jus...@UL...>]

Paul Kienzle <pki...@us...> wrote on Tue, 22 Feb 2005
01:09:38 -0500:

> FWIW, matlab also exhibits the alternating bright-dim stripes but less
> severely than yours.

For imrotate(eye(...), ..., ...) I just verified that for all of
"nearest", "bilinear" and "bicubic", Matlab's (6.5) and my code
produce *exactly* the same result, modulo the following:

- My code crops the image a little more aggressively than Matlab
  does. I round the size such that 90.1 and 90 degrees (e.g.) give the
  same result. Matlab uses the ceil. It's a matter of taste.

  Moreover, Matlab appears to pad the image with zeros, while I do not
  pad. Thus, Matlab fills in more values/produces a larger
  image. However, I do not see why we should pad; the value of zero is
  about as arbitrary as any other value. My code fills in (the
  arbitrary value of) zero wherever the result is not defined. Again,
  it's a matter of taste, but my method yields simpler code.

- Both Matlab and my code may produce an odd-size result image for an
  even-size source image, and vice versa. In those cases where
  Matlab's and my code produce resulting image sizes of opposing
  parity, the results are obviously not identical, but neither is more
  "correct" than the other.

Justus

--=20
Justus H. Piater, Ph.D.         http://www.montefiore.ulg.ac.be/~piater/
Institut Montefiore, B28        Phone: +32-4-366-2279
Universit=E9 de Li=E8ge, Belgium    Fax:   +32-4-366-2620

Re: [OctDev] imrotate

[Justus P. <Jus...@UL...>]

I feel honored that my code receives this thorough testing :-)

However, I don't see what's wrong with the code. Please explain to me
what you expect imrotate(eye(13),45, "...") to look like. It is
certainly *not* going to be a homogeneous horizontal line since we are
interpolating pixels into a new raster whose spacing is stretched by
sqrt(2). We will therefore see a symmetric structure of varying gray
values between zero and one, and that is wider than one pixel.

Remember that we're rotating images, not matrices.

Convince me that the code is wrong by presenting a correct result, and
I'll see into fixing it.

Cheers,
Justus


Jeff Orchard <jor...@cs...> wrote on Sat, 19 Feb 2005
14:55:39 -0500:

> I'm not sure the bilinear option is working.
>    imrotate(eye(13),45,"bilinear")
> and
>    imrotate(eye(13),40,"bilinear")


Paul Kienzle <pki...@us...> wrote on Sat, 19 Feb 2005
15:47:00 -0500:

> Yes, imrotate seems to be broken for all of bilinear, bicubic
> and nearest.  As Todd pointed out, 'nearest' is particularly
> glaring.

--=20
Justus H. Piater, Ph.D.         http://www.montefiore.ulg.ac.be/~piater/
Institut Montefiore, B28        Phone: +32-4-366-2279
Universit=E9 de Li=E8ge, Belgium    Fax:   +32-4-366-2620

Re: [OctDev] Re: Octave Wiki

[Todd N. <to...@gm...>]

> The problem ith a banned host page is that most spammer come in through
> proxies, so they just pick a new proxies and try again.. So a bannedhost
> page is a lame anti-spam measure.. It really needs to be upto date.. If
> you want an effective measure in the same vain, see
> http://blacklist.chongqed.org as a means of preventing links that match
> a certain regex... The people at chongqed keep this upto date, and you
> can see other links on their pages on how to set this up.
> 

Those regex's can be put in the BannedContent page and that would
prevent those sites from being advertised.  I don't know how often
http://blacklist.chongqed.org is updated but we could grab the list
from EmacsWiki to start off with as well.

It looks like all that is needed now is for a few volunteers to get an
admin password so they can modify the BannedContent and BannedHosts
page and check the wiki daily for new spam.

Todd

Re: [OctDev] Re: Octave Wiki

[David B. <Dav...@mo...>]

Etienne Grossmann wrote:

>  Hi Todd,
>
>I just added a BannedHosts page to the wiki. I will not maintain it or
>clean up after spammers (amongs other things, my wrists have limited
>typing capacity). I will only re-open the wiki if people on this list
>take the responsibility to clean up after spammers. Else, I'll just
>make the front page friendlier.
>  
>

The problem ith a banned host page is that most spammer come in through 
proxies, so they just pick a new proxies and try again.. So a bannedhost 
page is a lame anti-spam measure.. It really needs to be upto date.. If 
you want an effective measure in the same vain, see 
http://blacklist.chongqed.org as a means of preventing links that match 
a certain regex... The people at chongqed keep this upto date, and you 
can see other links on their pages on how to set this up.

Regards
david

[OctDev] Re: Octave Wiki

[Etienne G. <et...@cs...>]

  Hi Todd,

I just added a BannedHosts page to the wiki. I will not maintain it or
clean up after spammers (amongs other things, my wrists have limited
typing capacity). I will only re-open the wiki if people on this list
take the responsibility to clean up after spammers. Else, I'll just
make the front page friendlier.

  Etienne

On Sun, Feb 20, 2005 at 07:49:09PM -0600, Todd Neal wrote:
# Etienne,
# 
# 
# Etienne Grossmann wrote:
# > ...
# ># I believe that the only way for the Octave Wiki or generally any Wiki to 
# ># become self-policing is for it to be opened to all users.  Without the 
# ># ability for anyone to join in easily it may be difficult to grow a large 
# ># user base and without a large user base spam may be a huge problem.  It 
# ># is somewhat of a catch 22.  Without a large user base, spam may become 
# ># uncontrollable.  Without opening up the Wiki for possible spam, it is 
# ># difficult to attain a large user base.
# >
# >  I don't see why a a large community would discourage spamming. Could
# >you explain?
# > 
#  I didn't intend to mean that a large community would discourage 
# spamming, only that a large community could more easily combat spam. 
# The task of reverting pages would not fall down to a single user or two 
# and the load of fixing pages could be spread across many multiple users. 

To me, this sounds like pitting people against robots, in a task for
which robots are best suited. 


#  I usually check the recent pages on any wiki I visit and revert to the 
# last known good page if any of the first few pages look like spam.
# 
# ># A possible solution may be to allow some users who volunteer to act as 
# ># Wiki administrators and maintain the BannedContent and BannedHosts pages 
# ># (http://www.oddmuse.org/cgi-bin/wiki/Banning).  This would make it easy 
# ># to curtail spamming of the same site(s) and spam from the same few hosts.
# >
# >  Thanks for pointing this out to me, I did not know (or remember)
# >about the bannedhosts page. If you want to clean up after spammers and
# >keep updated the bannedhosts, I could list you as an administrator (as
# >soon as I find out how to).
# >
# >
# 
# We could also borrow the BannedContent page from EmacsWiki to start out:
# http://emacswiki.org/cw/BannedContent
# 
# This would hopefully keep spam to a trickle until we could add our own 
# regexes to match and prevent any new spam.  I'm not entirely sure how 
# this would work as it may become a game of "Whack-A-Mole" with the 
# spammers.  If they routinely use the same ISPs though it may be easier 
# to block entire ISP's that spammers frequent while still allowing the 
# majority of the users to access the Octave Wiki freely.
# 
# From the OddMuse documentation, it looks like to add an administrator 
# you need to modify the $AdminPass variable so that it contains several 
# passwords separated by a space 
# (http://www.oddmuse.org/cgi-bin/wiki/Passwords).
# 
# 
# Thanks, Todd
# 

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

[OctDev] Re: Octave Wiki

[Todd N. <to...@gm...>]

Etienne,


Etienne Grossmann wrote:
 > ...
> # I believe that the only way for the Octave Wiki or generally any Wiki to 
> # become self-policing is for it to be opened to all users.  Without the 
> # ability for anyone to join in easily it may be difficult to grow a large 
> # user base and without a large user base spam may be a huge problem.  It 
> # is somewhat of a catch 22.  Without a large user base, spam may become 
> # uncontrollable.  Without opening up the Wiki for possible spam, it is 
> # difficult to attain a large user base.
> 
>   I don't see why a a large community would discourage spamming. Could
> you explain?
>  
  I didn't intend to mean that a large community would discourage 
spamming, only that a large community could more easily combat spam. 
The task of reverting pages would not fall down to a single user or two 
and the load of fixing pages could be spread across many multiple users. 
  I usually check the recent pages on any wiki I visit and revert to the 
last known good page if any of the first few pages look like spam.

> # A possible solution may be to allow some users who volunteer to act as 
> # Wiki administrators and maintain the BannedContent and BannedHosts pages 
> # (http://www.oddmuse.org/cgi-bin/wiki/Banning).  This would make it easy 
> # to curtail spamming of the same site(s) and spam from the same few hosts.
> 
>   Thanks for pointing this out to me, I did not know (or remember)
> about the bannedhosts page. If you want to clean up after spammers and
> keep updated the bannedhosts, I could list you as an administrator (as
> soon as I find out how to).
> 
> 

We could also borrow the BannedContent page from EmacsWiki to start out:
http://emacswiki.org/cw/BannedContent

This would hopefully keep spam to a trickle until we could add our own 
regexes to match and prevent any new spam.  I'm not entirely sure how 
this would work as it may become a game of "Whack-A-Mole" with the 
spammers.  If they routinely use the same ISPs though it may be easier 
to block entire ISP's that spammers frequent while still allowing the 
majority of the users to access the Octave Wiki freely.

 From the OddMuse documentation, it looks like to add an administrator 
you need to modify the $AdminPass variable so that it contains several 
passwords separated by a space 
(http://www.oddmuse.org/cgi-bin/wiki/Passwords).


Thanks, Todd

[OctDev] Re: Octave Wiki

[Etienne G. <et...@cs...>]

  Hi Todd,



On Sat, Feb 19, 2005 at 08:15:20PM -0600, Todd Neal wrote:
# Dr. Grossmann,
# 
# On the Octave Wiki it states:
# Hopefully, this is only a temporary fix. This site has been badly 
# defaced recently. Thanks to David Bateman for repairing the damage, 
# ringing the alarm and proposing fixes. I have little time for 
# administration right now, but hope to soon find a solution that 
# preserves the "wiki" spirit in this site.
# 
# In light of this I thought that there may be enough interest in the Wiki 
# that it could opened completely.  Perhaps it could even be for a test 
# period, ie. open up full access for a week and see if the community at 

I left the wiki open by mistake a few weeks ago and had to clean it up
shortly after; I don't think it's worth repeating the experiment. The
spamming communuty would surely appreciate, though.


# large can keep spam to a minimum.
# 
# I believe that the only way for the Octave Wiki or generally any Wiki to 
# become self-policing is for it to be opened to all users.  Without the 
# ability for anyone to join in easily it may be difficult to grow a large 
# user base and without a large user base spam may be a huge problem.  It 
# is somewhat of a catch 22.  Without a large user base, spam may become 
# uncontrollable.  Without opening up the Wiki for possible spam, it is 
# difficult to attain a large user base.

  I don't see why a a large community would discourage spamming. Could
you explain?
 
# A possible solution may be to allow some users who volunteer to act as 
# Wiki administrators and maintain the BannedContent and BannedHosts pages 
# (http://www.oddmuse.org/cgi-bin/wiki/Banning).  This would make it easy 
# to curtail spamming of the same site(s) and spam from the same few hosts.

  Thanks for pointing this out to me, I did not know (or remember)
about the bannedhosts page. If you want to clean up after spammers and
keep updated the bannedhosts, I could list you as an administrator (as
soon as I find out how to).

  Cheers,

  Etienne

# 
# 
# Thanks,
# Todd

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

Re: [OctDev] imrotate

[Paul K. <pki...@us...>]

Yes, imrotate seems to be broken for all of bilinear, bicubic
and nearest.  As Todd pointed out, 'nearest' is particularly
glaring.

Can the users of this function please come up with a fix which
you are all happy with?

Here are some more tests you might include:

   % Make sure the dithering preserves pixel density
   t=zeros(1,5);
   for n=1:15; t(n) = sum(imrotate(eye(n),20,'bilinear')(:)); end
   assert(t,[1:15]);

   % Make sure the size matches the expected size assuming square pixels.
   angle=20; t=zeros(15,2);
   for n=1:15; t(n,:) = size(imrotate(ones(n,3*n),angle,'bilinear')); end
   a = angle*pi/180;
   x = ceil([(1:n);3*(1:n)]'*[cos(a) sin(a);sin(a) cos(a)]);
   assert(t,x);

Thanks,

- Paul

On Feb 19, 2005, at 2:55 PM, Jeff Orchard wrote:

>
> I'm not sure the bilinear option is working.
>
>   imrotate(eye(13),45,"bilinear")
>
> and
>
>   imrotate(eye(13),40,"bilinear")
>
> Jeff
>
>
> On Feb 16, 2005, at 12:48 AM, Todd Neal wrote:
>
>> On Tue, 15 Feb 2005 23:58:04 -0500, Paul Kienzle 
>> <pki...@us...> wrote:
>>> I replaced the old version of imrotate with what you sent.
>>>
>>> I would appreciate a few simple test cases which do not
>>> rely on a human visual system to determine if the result
>>> is correct.
>>>
>>> I tried the following:
>>>
>>>         X = rand(30);
>>>         Y = imrotate(imrotate(X,30,'bicubic'),-30,'bicubic');
>>>         norm(X(17+[1:5],17+[1:5])-Y(30+[1:5],30+[1:5]))
>>>         ans = 0.46103
>>>
>>> Using a smoother function worked better:
>>>
>>>         X = peaks(30);
>>>         Y = imrotate(imrotate(X,30,'bicubic'),-30,'bicubic');
>>>         norm(X(17+[1:5],17+[1:5])-Y(30+[1:5],30+[1:5]))
>>>         ans = 0.0036647
>>>
>>> Anyone have any better suggestions?
>>>
>>
>> I was looking for a few good test cases and came across using this as
>> a test case:
>>
>> imrotate(eye(20),45)
>>
>> The problem is displayed here (in a smaller case to fit in an email 
>> well):
>>
>> octave:18> imrotate(eye(13),45)
>> ans =
>>
>>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>>   1  0  0  1  0  0  0  1  0  0  1  0  0  0  1  0  0  1
>>   1  0  0  1  0  0  0  1  0  0  1  0  0  0  1  0  0  1
>>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>>
>>
>> Todd
>

Re: [OctDev] imrotate

[Jeff O. <jor...@cs...>]

I'm not sure the bilinear option is working.

   imrotate(eye(13),45,"bilinear")

and

   imrotate(eye(13),40,"bilinear")

Jeff


On Feb 16, 2005, at 12:48 AM, Todd Neal wrote:

> On Tue, 15 Feb 2005 23:58:04 -0500, Paul Kienzle 
> <pki...@us...> wrote:
>> I replaced the old version of imrotate with what you sent.
>>
>> I would appreciate a few simple test cases which do not
>> rely on a human visual system to determine if the result
>> is correct.
>>
>> I tried the following:
>>
>>         X = rand(30);
>>         Y = imrotate(imrotate(X,30,'bicubic'),-30,'bicubic');
>>         norm(X(17+[1:5],17+[1:5])-Y(30+[1:5],30+[1:5]))
>>         ans = 0.46103
>>
>> Using a smoother function worked better:
>>
>>         X = peaks(30);
>>         Y = imrotate(imrotate(X,30,'bicubic'),-30,'bicubic');
>>         norm(X(17+[1:5],17+[1:5])-Y(30+[1:5],30+[1:5]))
>>         ans = 0.0036647
>>
>> Anyone have any better suggestions?
>>
>
> I was looking for a few good test cases and came across using this as
> a test case:
>
> imrotate(eye(20),45)
>
> The problem is displayed here (in a smaller case to fit in an email 
> well):
>
> octave:18> imrotate(eye(13),45)
> ans =
>
>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>   1  0  0  1  0  0  0  1  0  0  1  0  0  0  1  0  0  1
>   1  0  0  1  0  0  0  1  0  0  1  0  0  0  1  0  0  1
>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>   0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
>
>
> Todd

Re: [OctDev] imrotate

[Paul K. <pki...@us...>]

On Feb 16, 2005, at 5:08 AM, Justus Piater wrote:

>> Using a smoother function worked better:
>>
>> 	X = peaks(30);
>> 	Y = imrotate(imrotate(X,30,'bicubic'),-30,'bicubic');
>> 	norm(X(17+[1:5],17+[1:5])-Y(30+[1:5],30+[1:5]))
>> 	ans = 0.0036647
>
> I like this. I suggest to use "crop", this saves indexing adjustments
> and makes the code more transparent and robust to future changes to
> the size of the rotated image. Moreover, Fourier does not seem to
> handle negative pixel values:
>
>   X = peaks(30);
>   X -= min(min(X));
>   Y = imrotate(imrotate(X, 30, "bicubic", "crop"), -30, "bicubic", 
> "crop");
>   norm(X(10:20,10:20) - Y(10:20,10:20))
>   ans = 0.076178
>
> This can now be used with all four interpolation methods.

This still begs the question of what is a 'good' value.  How about the
following:

    x=peaks(50);
    y=x; for i=1:5, y=imrotate(y,60,'bicubic','crop'); end
    norm((x-imrotate(y,59,'bicubic','crop'))(10:40,10:40))
      ans = 2.6138
    norm((x-imrotate(y,60,'bicubic','crop'))(10:40,10:40))
      ans = 0.069348
    norm((x-imrotate(y,61,'bicubic','crop'))(10:40,10:40))
      ans = 2.6850

This should be a pretty good test of slight over- or under- rotation.

I'm sure you already know the rotation is lossy:

     y=x=peaks(50);
     for i=1:6, y=imrotate(y,60,'bicubic','crop'); end
     norm((x-y)(10:40,10:40))
       ans = 0.069348
    for i=1:6, y=imrotate(y,60,'bicubic','crop'); end
    norm((x-y)(10:40,10:40))
       ans = 0.13736


> As a complementary test of the "nearest" method, I suggest to compare
> near-90-degree rotations to exact 90-degree rotations (only the latter
> are handled by rot90, with greetings to Todd!). For odd image sizes,
> the result should be exact:
>
>   X = rand(99);
>   Y = imrotate(X,  89.9, "nearest");
>   Z = imrotate(Y, -89.9, "nearest");
>   norm(X-Z)
>   ans = 0
>   norm(Y - imrotate(X, 90, "nearest"))
>   ans = 0
>
> Also try 90.1 degrees, and likewise around 180 and 270.
>
> I think it would be useful to add these test cases to imrotate.m.
>

Send me a patch and I will add it.

Embedded tests are run automatically.  E.g., I added the following test:

%!test
%! X = rand(19);
%! Z = imrotate(imrotate(X, 89.9, "nearest"), -89.9, "nearest");
%! assert(norm(X-Z),0);

See 'help test' for more details.

Thanks,

- Paul

Re: [OctDev] imrotate

[Justus P. <Jus...@UL...>]

> I would appreciate a few simple test cases which do not
> rely on a human visual system to determine if the result
> is correct.
>
> I tried the following:
>
> 	X =3D rand(30);
> 	Y =3D imrotate(imrotate(X,30,'bicubic'),-30,'bicubic');
> 	norm(X(17+[1:5],17+[1:5])-Y(30+[1:5],30+[1:5]))
> 	ans =3D 0.46103

Yes, for random images there's no hope...

> Using a smoother function worked better:
>
> 	X =3D peaks(30);
> 	Y =3D imrotate(imrotate(X,30,'bicubic'),-30,'bicubic');
> 	norm(X(17+[1:5],17+[1:5])-Y(30+[1:5],30+[1:5]))
> 	ans =3D 0.0036647

I like this. I suggest to use "crop", this saves indexing adjustments
and makes the code more transparent and robust to future changes to
the size of the rotated image. Moreover, Fourier does not seem to
handle negative pixel values:

  X =3D peaks(30);
  X -=3D min(min(X));
  Y =3D imrotate(imrotate(X, 30, "bicubic", "crop"), -30, "bicubic", "crop"=
);
  norm(X(10:20,10:20) - Y(10:20,10:20))
  ans =3D 0.076178

This can now be used with all four interpolation methods.

As a complementary test of the "nearest" method, I suggest to compare
near-90-degree rotations to exact 90-degree rotations (only the latter
are handled by rot90, with greetings to Todd!). For odd image sizes,
the result should be exact:

  X =3D rand(99);
  Y =3D imrotate(X,  89.9, "nearest");
  Z =3D imrotate(Y, -89.9, "nearest");
  norm(X-Z)
  ans =3D 0
  norm(Y - imrotate(X, 90, "nearest"))
  ans =3D 0

Also try 90.1 degrees, and likewise around 180 and 270.

I think it would be useful to add these test cases to imrotate.m.

Justus

--=20
Justus H. Piater, Ph.D.         http://www.montefiore.ulg.ac.be/~piater/
Institut Montefiore, B28        Phone: +32-4-366-2279
Universit=E9 de Li=E8ge, Belgium    Fax:   +32-4-366-2620

Re: [OctDev] imrotate

[Todd N. <to...@gm...>]

On Tue, 15 Feb 2005 23:58:04 -0500, Paul Kienzle <pki...@us...> wrote:
> I replaced the old version of imrotate with what you sent.
> 
> I would appreciate a few simple test cases which do not
> rely on a human visual system to determine if the result
> is correct.
> 
> I tried the following:
> 
>         X = rand(30);
>         Y = imrotate(imrotate(X,30,'bicubic'),-30,'bicubic');
>         norm(X(17+[1:5],17+[1:5])-Y(30+[1:5],30+[1:5]))
>         ans = 0.46103
> 
> Using a smoother function worked better:
> 
>         X = peaks(30);
>         Y = imrotate(imrotate(X,30,'bicubic'),-30,'bicubic');
>         norm(X(17+[1:5],17+[1:5])-Y(30+[1:5],30+[1:5]))
>         ans = 0.0036647
> 
> Anyone have any better suggestions?
> 

I was looking for a few good test cases and came across using this as
a test case:

imrotate(eye(20),45)

The problem is displayed here (in a smaller case to fit in an email well):

octave:18> imrotate(eye(13),45)
ans =

  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
  1  0  0  1  0  0  0  1  0  0  1  0  0  0  1  0  0  1
  1  0  0  1  0  0  0  1  0  0  1  0  0  0  1  0  0  1
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0
  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0


Todd

Re: [OctDev] imrotate

[Paul K. <pki...@us...>]

On Feb 13, 2005, at 2:35 PM, Justus Piater wrote:

> I've fixed the problems reported by Todd Neal, and added support for
> rot90(). Note that for "crop" one has to do the cropping after the
> rot90(). Moreover, if the image dimensions are not of equal parity
> (odd width and even height, or vice versa), a +/- 90 degree rotation
> entails interpolation. This implies that rot90() cannot be used for
> such rotations.
>
> The new code is designed to behave smoothly across small increments of
> rotation angle, rot90 or not. The result should be exactly the same,
> whether or not rot90 is used.
>
> Please try out the code (Todd!) and tell me what you think. Once I
> have Todd's approval, this code (imrotate.m and imrotate_Fourier.m)
> should replace the existing version of imrotate in CVS.
>
> There are two test functions, testimrotate and testrot90. Look at
> their code and play with them. The other files are needed by these
> two.
>

I replaced the old version of imrotate with what you sent.

I would appreciate a few simple test cases which do not
rely on a human visual system to determine if the result
is correct.

I tried the following:

	X = rand(30);
	Y = imrotate(imrotate(X,30,'bicubic'),-30,'bicubic');
	norm(X(17+[1:5],17+[1:5])-Y(30+[1:5],30+[1:5]))
	ans = 0.46103

Using a smoother function worked better:

	X = peaks(30);
	Y = imrotate(imrotate(X,30,'bicubic'),-30,'bicubic');
	norm(X(17+[1:5],17+[1:5])-Y(30+[1:5],30+[1:5]))
	ans = 0.0036647

Anyone have any better suggestions?

Thanks,

- Paul

Re: [OctDev] Re: imrotate

[Paul K. <pki...@us...>]

>
>>> For example, what happens if the angle is 269.999999?  Discretizing
>>> the angle before checking if it is 270 would be useful.
>>
>> I strongly disagree. rot90 should only be used for _exact_ multiples
>> of 90 degrees. If not, how do we choose the tolerance? If the image is
>> large enough, the result will be different. Let the user decide. The
>> user can discretize the angle before calling imrotate() if s/he wants
>> to.
>>
>
> I agree with Justus on this point, for a very large image a small
> angle change will result in a different rotated image.  However it may
> be possible to do something in the manner of this pseudocode:
>
> theta=89.99
> cornersTheta = compute the corners for 89.99;
> cornersNinety = compute the corners for 90.00
>
> if cornersTheta = cornersNinety
>     theta = 90;
> end;
>
>
> The speedup for the few cases where the angle is so close to a
> multiple of 90 and the image is small enough that it makes no
> difference may not be worth the expense of doing the checks to
> determine this.


The reason you don't want to check for multiples of 90 is that
floating point arithmetic is not exact.  For the sake of argument,
lets say that the rotation angle comes from acos(x) with x
approximately 0:

	> acos(eps)/pi*180-90
	ans =  -1.4211e-14

This is an angle which is almost but not quite 90.

For large matrices, the cost of testing the corners before choosing
the algorithm is trivial compared to the rotation.  For small
matrices, processing time will dominated by interpreter speed and
one or two extra lines amongst hundreds is again a small penalty.

Whether or not this optimization is worthwhile depends on how
frequently these near 90*n cases occur vs. speed gain from the
simple operations.  I'll leave that to the users of imrotate to
decide.

- Paul

[OctDev] Re: imrotate

[Todd N. <to...@gm...>]

On Sun, 13 Feb 2005 20:35:26 +0100, Justus Piater
<Jus...@ul...> wrote:
> Please try out the code (Todd!) and tell me what you think. Once I
> have Todd's approval, this code (imrotate.m and imrotate_Fourier.m)
> should replace the existing version of imrotate in CVS.
> 
I've tried it out and it works fine, much better than the previous version.

> There are two test functions, testimrotate and testrot90. Look at
> their code and play with them. The other files are needed by these
> two.
> 
> Paul Kienzle <pki...@us...> wrote on Thu, 10 Feb 2005
> 07:09:00 -0500:
> 
> > I'm disappointed that the current imrotate gives an incorrect result you
> > showed in your example, and would like to see that addressed as well.
> 
> Just to clarify: The corners were off by half a pixel due to a
> round-off error. This error is dramatic for small matrices, but barely
> noticeable for anything that merits being called an "image".
> Nevertheless, bug is bug... and is fixed.

I thought it may have been imperceptible with large images but am glad
that you found a way fix it anyway, the fixes that I implemented were
definitely not the greatest.

> > For example, what happens if the angle is 269.999999?  Discretizing
> > the angle before checking if it is 270 would be useful.
> 
> I strongly disagree. rot90 should only be used for _exact_ multiples
> of 90 degrees. If not, how do we choose the tolerance? If the image is
> large enough, the result will be different. Let the user decide. The
> user can discretize the angle before calling imrotate() if s/he wants
> to.
> 

I agree with Justus on this point, for a very large image a small
angle change will result in a different rotated image.  However it may
be possible to do something in the manner of this pseudocode:

theta=89.99
cornersTheta = compute the corners for 89.99;
cornersNinety = compute the corners for 90.00

if cornersTheta = cornersNinety
    theta = 90;
end;


The speedup for the few cases where the angle is so close to a
multiple of 90 and the image is small enough that it makes no
difference may not be worth the expense of doing the checks to
determine this.

> Todd Neal <to...@gm...> wrote on Thu, 10 Feb 2005 09:24:03 -0600:
> 
> > I also modified the special cases so that it doesn't rely on rot90
> 
> Why? rot90 does exactly what's needed here. My code uses it happily.
> 

I used array indexing and transposing to achieve the 90,180, and 270
degree rotations.  If you look at rot90.m, the rotation is
accomplished by these methods.  Including the code in imrotate.m saves
a function call to rot90 and should be a bit faster.


Todd

[OctDev] Re: imrotate

[Todd N. <to...@gm...>]

That sounds great, I'm going to try to get some time to take a close look at it.


> Todd Neal <to...@gm...> wrote on Thu, 10 Feb 2005 09:24:03 -0600:
> 
> > I also modified the special cases so that it doesn't rely on rot90
> 
> Why? rot90 does exactly what's needed here. My code uses it happily.

I used array indexing and transposing to achieve the 90,180, and 270
degree rotations.  This effectively saved a function call to rot90.  I
haven't done any benchmarks but just assumed it would be quicker this
way.

Todd

[OctDev] imrotate

[Justus P. <Jus...@UL...>]

Hi,

I've fixed the problems reported by Todd Neal, and added support for
rot90(). Note that for "crop" one has to do the cropping after the
rot90(). Moreover, if the image dimensions are not of equal parity
(odd width and even height, or vice versa), a +/- 90 degree rotation
entails interpolation. This implies that rot90() cannot be used for
such rotations.

The new code is designed to behave smoothly across small increments of
rotation angle, rot90 or not. The result should be exactly the same,
whether or not rot90 is used.

Please try out the code (Todd!) and tell me what you think. Once I
have Todd's approval, this code (imrotate.m and imrotate_Fourier.m)
should replace the existing version of imrotate in CVS.

There are two test functions, testimrotate and testrot90. Look at
their code and play with them. The other files are needed by these
two.


Paul Kienzle <pki...@us...> wrote on Thu, 10 Feb 2005
07:09:00 -0500:

> I'm disappointed that the current imrotate gives an incorrect result you
> showed in your example, and would like to see that addressed as well.

Just to clarify: The corners were off by half a pixel due to a
round-off error. This error is dramatic for small matrices, but barely
noticeable for anything that merits being called an "image".
Nevertheless, bug is bug... and is fixed.

> For example, what happens if the angle is 269.999999?  Discretizing
> the angle before checking if it is 270 would be useful.

I strongly disagree. rot90 should only be used for _exact_ multiples
of 90 degrees. If not, how do we choose the tolerance? If the image is
large enough, the result will be different. Let the user decide. The
user can discretize the angle before calling imrotate() if s/he wants
to.


Todd Neal <to...@gm...> wrote on Thu, 10 Feb 2005 09:24:03 -0600:

> I also modified the special cases so that it doesn't rely on rot90

Why? rot90 does exactly what's needed here. My code uses it happily.


Todd Neal <to...@gm...> wrote on Thu, 10 Feb 2005 12:54:06 -0600:

> I am working on imresize and would be interested in seeing the
> bicubic interpolation code.

Here it is :-). The bicubic interpolation code is very general and
could be moved out of imrotate.m for use with imresize and
others. However, I don't think this is the right way to go; there are
more efficient algorithms for interpolation along parralel, regular
grids, e.g. Robert G. Keys, Cubic Convolution Interpolation for
Digital Image Processing, IEEE Trans. on Acoustics, Speech, and Signal
Processing 29(6) 1981, 1153-1160. If you want to do the community a
service, add such bicubic interpolation to interp2.m, and base
imresize() on that. You may also want to check out "help
rotate_scale".

Good luck!
Justus

Re: [OctDev] Wiki editing denied

[Etienne G. <et...@cs...>]

  Hi Felipe,

I agree this way of protecting the wiki is rather clunky. As it is, I
have little time to maintain the wiki, but you are free to set up
another one with whatever protection you feel is appropriate. If John
finds the new wiki acceptable, he can then have wiki.octave.org point
to it, at which point I would discontinue the wiki I'm presently
maintaining.

  Cheers,

  Etienne

PS : Do you now manage to edit the wiki right now?

PPS: Wikipedia's def of "wiki" http://en.wikipedia.org/wiki/Wiki does
     not exclude requiring registration to edit a wiki.

On Sat, Feb 12, 2005 at 08:24:27PM -0400, Felipe G. Nievinski wrote:
# OK, thanks.
# 
# Look, I've read about your reasons to block editing on that Wiki.
# But I think you should use some other workaround (daily backups, 
# restored in case of troubles?).
# In my opinion a Wiki which is not free to anybody edit should not be 
# called Wiki.
# 
# Please do not take these comments as criticism, but as suggestions to 
# make it better.
# 
# Thank you once again.
# 
# Felipe.
# 
# Etienne Grossmann wrote:
# >
# >  Hi Felipe,
# >
# >you should now be able to edit the wiki. I haven't added your
# >contribution because I am busy right now.
# >
# >  Cheers and thanks for your help w/ the wiki,
# >
# >  Etienne
# >
# >On Thu, Feb 10, 2005 at 08:07:48PM -0400, Felipe G. Nievinski wrote:
# ># > Editing not allowed for 131.202.141.24 / 12599.gge.unb.ca: user, ip,
# ># > or network is blocked.
# ># >
# ># > Please contact octave-dev at lists.sourceforge.net, specifying your
# ># > IP, if you would like to contribute to this site
# ># 
# ># Please, I'd like to contribute the following piece of code to 
# ># http://wiki.octave.org/wiki.pl?TipsTricks
# ># 
# ># 
# ># function experience
# ># 
# ># %!test
# ># %! experience_design_mat
# ># %! experience_obs_eqs
# ># %! assert (experience_design_mat == pi);
# ># %! assert (experience_obs_eqs == exp(1));
# ># %!
# ># %! endfunction  % this is a trick.
# ># %! % now we can declare functions to be used by the test above.
# ># %!
# ># %! function a = experience_design_mat
# ># %!     a = pi;
# ># %! endfunction
# ># %!
# ># %! function b = experience_obs_eqs
# ># %!     b = exp(1);
# ># %! % endfunction: don't add it here. Let test() do it.
# ># 
# ># 
# ># -------------------------------------------------------
# ># SF email is sponsored by - The IT Product Guide
# ># Read honest & candid reviews on hundreds of IT Products from real users.
# ># Discover which products truly live up to the hype. Start reading now.
# ># http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
# ># _______________________________________________
# ># Octave-dev mailing list
# ># Oct...@li...
# ># https://lists.sourceforge.net/lists/listinfo/octave-dev
# >
# 

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

Re: [OctDev] Wiki editing denied

[Etienne G. <et...@cs...>]

  Hi Felipe,

you should now be able to edit the wiki. I haven't added your
contribution because I am busy right now.

  Cheers and thanks for your help w/ the wiki,

  Etienne

On Thu, Feb 10, 2005 at 08:07:48PM -0400, Felipe G. Nievinski wrote:
# > Editing not allowed for 131.202.141.24 / 12599.gge.unb.ca: user, ip,
# > or network is blocked.
# >
# > Please contact octave-dev at lists.sourceforge.net, specifying your
# > IP, if you would like to contribute to this site
# 
# Please, I'd like to contribute the following piece of code to 
# http://wiki.octave.org/wiki.pl?TipsTricks
# 
# 
# function experience
# 
# %!test
# %! experience_design_mat
# %! experience_obs_eqs
# %! assert (experience_design_mat == pi);
# %! assert (experience_obs_eqs == exp(1));
# %!
# %! endfunction  % this is a trick.
# %! % now we can declare functions to be used by the test above.
# %!
# %! function a = experience_design_mat
# %!     a = pi;
# %! endfunction
# %!
# %! function b = experience_obs_eqs
# %!     b = exp(1);
# %! % endfunction: don't add it here. Let test() do it.
# 
# 
# -------------------------------------------------------
# SF email is sponsored by - The IT Product Guide
# Read honest & candid reviews on hundreds of IT Products from real users.
# Discover which products truly live up to the hype. Start reading now.
# http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
# _______________________________________________
# Octave-dev mailing list
# Oct...@li...
# https://lists.sourceforge.net/lists/listinfo/octave-dev

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

[OctDev] Wiki editing denied

[Felipe G. N. <f.n...@un...>]

 > Editing not allowed for 131.202.141.24 / 12599.gge.unb.ca: user, ip,
 > or network is blocked.
 >
 > Please contact octave-dev at lists.sourceforge.net, specifying your
 > IP, if you would like to contribute to this site

Please, I'd like to contribute the following piece of code to 
http://wiki.octave.org/wiki.pl?TipsTricks


function experience

%!test
%! experience_design_mat
%! experience_obs_eqs
%! assert (experience_design_mat == pi);
%! assert (experience_obs_eqs == exp(1));
%!
%! endfunction  % this is a trick.
%! % now we can declare functions to be used by the test above.
%!
%! function a = experience_design_mat
%!     a = pi;
%! endfunction
%!
%! function b = experience_obs_eqs
%!     b = exp(1);
%! % endfunction: don't add it here. Let test() do it.

Re: [OctDev] wiki whitelist request

[Etienne G. <et...@cs...>]

  Which reminds me, I should check this out too ...

On Tue, Feb 08, 2005 at 04:21:51PM -0800, Noam Sturmwind <ns...@ca...> wrote:
# I see that you're looking for a way to prevent wiki spam. We have a wiki 
# at http://community.nbtsc.org/wiki which has some reasonable effective 
# automatic spam blocking (although it is supplemented by an active 
# user base who frequently check the recent changes list, and so notice any 
# spam which slips through).
# 
# Perhaps Aredridel (are...@nb...) can give you some details about 
# how we're blocking spam.
# 
# Noam

  Etienne

On Thu, Feb 10, 2005 at 03:32:17PM -0500, D Goel wrote:
# 
# hi 
# 
# When I try to edit the wiki, i get the following message:
# 
#  Editing not allowed for 12.166.244.34 / 12.166.244.34: user, ip, or
#  network is blocked.
# 
#  Please contact octave-dev at lists.sourceforge.net, specifying your
#  IP, if you would like to contribute to this site
# 
# 
# I would like to be whitelisted.  The IPs I use are the above, and I
# also use 24.197.xx.xx (dynamic), current being: 24.197.153.99.
# 
# I am a happy user of octave, and also originally launched the wiki.
# 
# 
# thanks 
# DG                                 http://gnufans.net/
# --
# 
# 
# 
# -------------------------------------------------------
# SF email is sponsored by - The IT Product Guide
# Read honest & candid reviews on hundreds of IT Products from real users.
# Discover which products truly live up to the hype. Start reading now.
# http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
# _______________________________________________
# Octave-dev mailing list
# Oct...@li...
# https://lists.sourceforge.net/lists/listinfo/octave-dev

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

Re: [OctDev] wiki whitelist request

[Etienne G. <et...@cs...>]

  Hi D,

should be done. Please let me know whether you can edit the wiki and
thanks for proposing to contribute.

  Cheers,

  Etienne

On Thu, Feb 10, 2005 at 03:32:17PM -0500, D Goel wrote:
# 
# hi 
# 
# When I try to edit the wiki, i get the following message:
# 
#  Editing not allowed for 12.166.244.34 / 12.166.244.34: user, ip, or
#  network is blocked.
# 
#  Please contact octave-dev at lists.sourceforge.net, specifying your
#  IP, if you would like to contribute to this site
# 
# 
# I would like to be whitelisted.  The IPs I use are the above, and I
# also use 24.197.xx.xx (dynamic), current being: 24.197.153.99.
# 
# I am a happy user of octave, and also originally launched the wiki.
# 
# 
# thanks 
# DG                                 http://gnufans.net/
# --
# 
# 
# 
# -------------------------------------------------------
# SF email is sponsored by - The IT Product Guide
# Read honest & candid reviews on hundreds of IT Products from real users.
# Discover which products truly live up to the hype. Start reading now.
# http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
# _______________________________________________
# Octave-dev mailing list
# Oct...@li...
# https://lists.sourceforge.net/lists/listinfo/octave-dev

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

[OctDev] wiki whitelist request

[D G. <de...@gn...>]

hi 

When I try to edit the wiki, i get the following message:

 Editing not allowed for 12.166.244.34 / 12.166.244.34: user, ip, or
 network is blocked.

 Please contact octave-dev at lists.sourceforge.net, specifying your
 IP, if you would like to contribute to this site


I would like to be whitelisted.  The IPs I use are the above, and I
also use 24.197.xx.xx (dynamic), current being: 24.197.153.99.

I am a happy user of octave, and also originally launched the wiki.


thanks 
DG                                 http://gnufans.net/
--

[OctDev] Re: imrotate.m

[Todd N. <to...@gm...>]

On Thu, 10 Feb 2005 19:36:13 +0100, Justus Piater
<Jus...@ul...> wrote:
> Great to see that others too are interested in imrotate :-)
>
> Todd, thanks for reporting the half-pixel alignment problem revealed
> by the modulo-90 rotations. I think that the cause is incorrect
> round-off during computation of the center of rotation and/or the
> projection of the corners. I hope to be able to look into this over
> the weekend.
>

I think the problem has to do with the rounding of the corners as well.
octave:15> imrotate(a,180)
corners =

   0.00000   0.00000
  -3.00000  -1.00000
  -3.00000  -3.00000
  -1.00000  -3.00000

ans =

  9  8  7
  6  5  4
  3  2  1
  0  0  0

After rounding the corners:
octave:16> imrotate(a,180)
corners =

   0   0
  -3  -1
  -3  -3
  -1  -3

ans =

  9  8  7
  6  5  4
  3  2  1

> In any case, a solution will have to be correct with respect to the
> homography (which is sub-pixel accurate when used with
> interpolation). In particular, the accelerated versions of the
> modulo-90 rotations must produce exactly the same result as the
> projection through the homography.
>
If the corners matrix is rounded then imrotate(a,90) == rot90(a) so
the accelerated version is equivalent.    On second thought round is
probably not the proper way to handle the corners matrix, maybe
something like "round to the nearest integer if it is within some
value epsilon", this should fix the multiple of 90 degree rotations.

> BTW, I submitted a new version of imrotate to octave-dev on February
> 1st that adds bicubic interpolation and reintegrates Fourier
> interpolation.
>

I thought it may have been fixed in this version but it wasn't
committed to CVS and I was not on the list at the time, can I get this
patch ?  I am working on imresize and would be interested in seeing
the bicubic interpolation code.  I am trying to clone Matlab's
bilinear interpolation from looking at the results of a resized matrix
but I think that  it is possible that Matlab is not doing an actual
bilinear interpolation and only something extremely similar.

Thanks, Todd

[OctDev] Re: imrotate.m

[Justus P. <Jus...@UL...>]

Great to see that others too are interested in imrotate :-)

Todd, thanks for reporting the half-pixel alignment problem revealed
by the modulo-90 rotations. I think that the cause is incorrect
round-off during computation of the center of rotation and/or the
projection of the corners. I hope to be able to look into this over
the weekend.

In any case, a solution will have to be correct with respect to the
homography (which is sub-pixel accurate when used with
interpolation). In particular, the accelerated versions of the
modulo-90 rotations must produce exactly the same result as the
projection through the homography.

BTW, I submitted a new version of imrotate to octave-dev on February
1st that adds bicubic interpolation and reintegrates Fourier
interpolation.

Cheers,
Justus

--=20
Justus H. Piater, Ph.D.         http://www.montefiore.ulg.ac.be/~piater/
Institut Montefiore, B28        Phone: +32-4-366-2279
Universit=E9 de Li=E8ge, Belgium    Fax:   +32-4-366-2620