Image rotation

Hi Everybody,

I'm working on a program that displays an analog clock on the screen of a Raspberry Pi computer.  It has options to display different clock hands from simple to fancy.  The simple hands are drawn directly.  The fancy hands are pre made images (black on white).  The pre made images point up to twelve to start and therefor need to be rotated around a point in the shaft of the clock hand.  My first pass at rotating those images was I think the standard take each point in the image, one at a time, do some trig math to see where the point should be rotated to and draw it there.  This mostly worked but it resultant image ended up with artifacts of dots and lines that were not in the original image.  They, I think, are caused by some of the adjacent points from the original image, becoming one point in the rotated image, thus leaving holes.

My son, Alex happens to be taking an imaging course at Rutgers.  He told me I needed to run a couple of filters on the resultant image that would fill in the holes.  He said I needed to dilate and then erode the image.  I wrote the code to do this and it worked as advertised.

I then thought is there some way to rotate an image that doesn't create the artifacts in the first place.  I asked Alex but his course didn't cover rotation algorithms, it was just assumed one would call some existing rotation function.

I then had the idea of looking from the rotated image back to the original image.  Meaning for every point (pixel) in the rotated image, I would calculate where it came from in the original image.  If it was from a point outside the original image, I would ignore it (it would be the background color).  This insured that every pixel that should be in the rotated image was present even if it was the same as one of its neighbors.  I worried that the rotated image would be a little blurry.  That concern turned out to be unwarranted.  I tried this on both black and white images and full color images and they all look great.

Does anyone know if I have invented something new or just reinvented something old?

My formal education in computer science is decades old.  When I was in school there was little to no image manipulation.  Now, it seems somethings are not taught because they are just expected to be an available tool and they spend more time on things like character and face recognition.  So, I'm hoping someone in this group has some knowledge obtained when image rotation may have been taught.

Lou

I did something I think is similar some years ago.

At one point, I developed a topside control system for robotic submersibles.

Part of the display, was a rotating compass, along with rotating gauges to show pitch and roll.

So I had an image, that I needed to be able to rotate by a set angle, but it had to be very quick.

Windows has a plgblt (parallelogram blt) API, which is what I used.

https://docs.microsoft.com/en-us/windows/desktop/api/wingdi/nf-wingdi-plgblt

Basically you specify the drawing area, and 3 corners, which are the 3 corners of your original

image, rotated to the desired angle (in radians), and Windows would then take care of the rotation

of the image for you.  It was lightning fast, and you don't have to worry about gaps in the roatation

of each pixel....you only have to rotate 3 points.

I implemented this by creating a subclass of CwExtendedComposite, and used that for the widget

class of the part I created.

I still have these classes somewhere, so if you need more than this, let me know, and I will look them

up.

Hope that helps...

Regards,

Julian Ford

On Saturday, December 8, 2018 at 9:55:03 AM UTC-5, Louis LaBrunda wrote:

Hi Everybody,

I'm working on a program that displays an analog clock on the screen of a Raspberry Pi computer.  It has options to display different clock hands from simple to fancy.  The simple hands are drawn directly.  The fancy hands are pre made images (black on white).  The pre made images point up to twelve to start and therefor need to be rotated around a point in the shaft of the clock hand.  My first pass at rotating those images was I think the standard take each point in the image, one at a time, do some trig math to see where the point should be rotated to and draw it there.  This mostly worked but it resultant image ended up with artifacts of dots and lines that were not in the original image.  They, I think, are caused by some of the adjacent points from the original image, becoming one point in the rotated image, thus leaving holes.

My son, Alex happens to be taking an imaging course at Rutgers.  He told me I needed to run a couple of filters on the resultant image that would fill in the holes.  He said I needed to dilate and then erode the image.  I wrote the code to do this and it worked as advertised.

I then thought is there some way to rotate an image that doesn't create the artifacts in the first place.  I asked Alex but his course didn't cover rotation algorithms, it was just assumed one would call some existing rotation function.

I then had the idea of looking from the rotated image back to the original image.  Meaning for every point (pixel) in the rotated image, I would calculate where it came from in the original image.  If it was from a point outside the original image, I would ignore it (it would be the background color).  This insured that every pixel that should be in the rotated image was present even if it was the same as one of its neighbors.  I worried that the rotated image would be a little blurry.  That concern turned out to be unwarranted.  I tried this on both black and white images and full color images and they all look great.

Does anyone know if I have invented something new or just reinvented something old?

My formal education in computer science is decades old.  When I was in school there was little to no image manipulation.  Now, it seems somethings are not taught because they are just expected to be an available tool and they spend more time on things like character and face recognition.  So, I'm hoping someone in this group has some knowledge obtained when image rotation may have been taught.

Lou

Thanks for the reply.  Rotating the image is a little slow in Smalltalk code but not bad.  I am caching the rotated images so that speeds things up a little.  It is also a little slow painting the rotated image on top of the underling photo.  Not sure why.  I am involved with something else for a little while so I will look into speeding things up later.

I'm still wondering how images are rotated at the pixel level.  Does one start with the image to be rotated and calculate where the pixel goes or does one look at the target image and calculate where the pixel came from?  I do the later and I'm wondering if that is a new approach?

Lou

On Tuesday, December 11, 2018 at 9:44:25 AM UTC-5, [hidden email] wrote:

Hi, Lou.

I did something I think is similar some years ago.

At one point, I developed a topside control system for robotic submersibles.

Part of the display, was a rotating compass, along with rotating gauges to show pitch and roll.

So I had an image, that I needed to be able to rotate by a set angle, but it had to be very quick.

Windows has a plgblt (parallelogram blt) API, which is what I used.

<a href="https://docs.microsoft.com/en-us/windows/desktop/api/wingdi/nf-wingdi-plgblt" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fdesktop%2Fapi%2Fwingdi%2Fnf-wingdi-plgblt\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFAg6rcuvCo8hmEikgcD-veRPP0yQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fwindows%2Fdesktop%2Fapi%2Fwingdi%2Fnf-wingdi-plgblt\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFAg6rcuvCo8hmEikgcD-veRPP0yQ&#39;;return true;">https://docs.microsoft.com/en-us/windows/desktop/api/wingdi/nf-wingdi-plgblt

Basically you specify the drawing area, and 3 corners, which are the 3 corners of your original

image, rotated to the desired angle (in radians), and Windows would then take care of the rotation

of the image for you.  It was lightning fast, and you don't have to worry about gaps in the roatation

of each pixel....you only have to rotate 3 points.

I implemented this by creating a subclass of CwExtendedComposite, and used that for the widget

class of the part I created.

I still have these classes somewhere, so if you need more than this, let me know, and I will look them

up.

Hope that helps...

Regards,

Julian Ford

On Saturday, December 8, 2018 at 9:55:03 AM UTC-5, Louis LaBrunda wrote:

Hi Everybody,

I'm working on a program that displays an analog clock on the screen of a Raspberry Pi computer.  It has options to display different clock hands from simple to fancy.  The simple hands are drawn directly.  The fancy hands are pre made images (black on white).  The pre made images point up to twelve to start and therefor need to be rotated around a point in the shaft of the clock hand.  My first pass at rotating those images was I think the standard take each point in the image, one at a time, do some trig math to see where the point should be rotated to and draw it there.  This mostly worked but it resultant image ended up with artifacts of dots and lines that were not in the original image.  They, I think, are caused by some of the adjacent points from the original image, becoming one point in the rotated image, thus leaving holes.

My son, Alex happens to be taking an imaging course at Rutgers.  He told me I needed to run a couple of filters on the resultant image that would fill in the holes.  He said I needed to dilate and then erode the image.  I wrote the code to do this and it worked as advertised.

I then thought is there some way to rotate an image that doesn't create the artifacts in the first place.  I asked Alex but his course didn't cover rotation algorithms, it was just assumed one would call some existing rotation function.

I then had the idea of looking from the rotated image back to the original image.  Meaning for every point (pixel) in the rotated image, I would calculate where it came from in the original image.  If it was from a point outside the original image, I would ignore it (it would be the background color).  This insured that every pixel that should be in the rotated image was present even if it was the same as one of its neighbors.  I worried that the rotated image would be a little blurry.  That concern turned out to be unwarranted.  I tried this on both black and white images and full color images and they all look great.

Does anyone know if I have invented something new or just reinvented something old?

My formal education in computer science is decades old.  When I was in school there was little to no image manipulation.  Now, it seems somethings are not taught because they are just expected to be an available tool and they spend more time on things like character and face recognition.  So, I'm hoping someone in this group has some knowledge obtained when image rotation may have been taught.

Lou

I like the plgblt option, because it is quick enough to show a spinning compass image, but also because I don;t have to worry about

the math for every pixel..just those 3 points.  And for those 3 points, I tale the original location, and apply the rotation to yield

the new locations.

Good luck!

Julian

On Saturday, December 8, 2018 at 9:55:03 AM UTC-5, Louis LaBrunda wrote:

Hi Everybody,

I'm working on a program that displays an analog clock on the screen of a Raspberry Pi computer.  It has options to display different clock hands from simple to fancy.  The simple hands are drawn directly.  The fancy hands are pre made images (black on white).  The pre made images point up to twelve to start and therefor need to be rotated around a point in the shaft of the clock hand.  My first pass at rotating those images was I think the standard take each point in the image, one at a time, do some trig math to see where the point should be rotated to and draw it there.  This mostly worked but it resultant image ended up with artifacts of dots and lines that were not in the original image.  They, I think, are caused by some of the adjacent points from the original image, becoming one point in the rotated image, thus leaving holes.

My son, Alex happens to be taking an imaging course at Rutgers.  He told me I needed to run a couple of filters on the resultant image that would fill in the holes.  He said I needed to dilate and then erode the image.  I wrote the code to do this and it worked as advertised.

I then thought is there some way to rotate an image that doesn't create the artifacts in the first place.  I asked Alex but his course didn't cover rotation algorithms, it was just assumed one would call some existing rotation function.

I then had the idea of looking from the rotated image back to the original image.  Meaning for every point (pixel) in the rotated image, I would calculate where it came from in the original image.  If it was from a point outside the original image, I would ignore it (it would be the background color).  This insured that every pixel that should be in the rotated image was present even if it was the same as one of its neighbors.  I worried that the rotated image would be a little blurry.  That concern turned out to be unwarranted.  I tried this on both black and white images and full color images and they all look great.

Does anyone know if I have invented something new or just reinvented something old?

My formal education in computer science is decades old.  When I was in school there was little to no image manipulation.  Now, it seems somethings are not taught because they are just expected to be an available tool and they spend more time on things like character and face recognition.  So, I'm hoping someone in this group has some knowledge obtained when image rotation may have been taught.

Lou

Thanks for checking this.  So, I reinvented something old.  Still, not bad, as I couldn't find anything (not that my search was exhaustive) that said this is the way rotation is done.

Lou

On Monday, December 17, 2018 at 2:28:41 AM UTC-5, Norbert Schlemmer wrote:

Hi Lou

Does anyone know if I have invented something new or just reinvented something old?

Spoken to a colleague from the  TU Wien (Vienna):

"No, this is the standard way to do it. See any image processing book like  <a href="http://szeliski.org/Book/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fszeliski.org%2FBook%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEFSBnY7awLxMlTGnRZNSM0kSItpA&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fszeliski.org%2FBook%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEFSBnY7awLxMlTGnRZNSM0kSItpA&#39;;return true;">http://szeliski.org/Book/

Regards

Norbert

tobRotated180, tobRotated270 and tobRotated90.

We use these when printing landscape pages in a print run - we actually only print portrait pages so we rotate all landscape pages accordingly

David

On Monday, December 17, 2018 at 1:36:25 PM UTC, Louis LaBrunda wrote:

Hi Norbert,

Thanks for checking this.  So, I reinvented something old.  Still, not bad, as I couldn't find anything (not that my search was exhaustive) that said this is the way rotation is done.

Lou

On Monday, December 17, 2018 at 2:28:41 AM UTC-5, Norbert Schlemmer wrote:

Hi Lou

Does anyone know if I have invented something new or just reinvented something old?

Spoken to a colleague from the  TU Wien (Vienna):

"No, this is the standard way to do it. See any image processing book like  <a href="http://szeliski.org/Book/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fszeliski.org%2FBook%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEFSBnY7awLxMlTGnRZNSM0kSItpA&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fszeliski.org%2FBook%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEFSBnY7awLxMlTGnRZNSM0kSItpA&#39;;return true;">http://szeliski.org/Book/

Regards

Norbert

I know about Visibility and these methods.  As their names imply, they only rotate in 90 degree increments.  I needed to rotate bu any amount.  This is more complicated as the math requires trigonometric functions.  No big deal, just a little more complicated.  The Visibility also seem to use my first thought of taking a pixel, calculating where it goes and putting it there.  At other than 90 degree angles, that leaves gaps.  My first try to fix the gaps was to write code to dilate and then erode the image.  For the simple images I needed, that worked fine.

I thought about the problem more and realized that if I went over every point in the new image and calculated where it came from, that, that would result in a new image with out gaps.  The rotation code I had already written was easily modified to do the rotation this way.  That worked great and eliminated the need for the dilate and then erode filter code.  I started this post to learn if I had invented something new or reinvented something old.  It seems it is the later.

Lou

On Tuesday, December 18, 2018 at 6:32:39 AM UTC-5, Totally Objects wrote:

Lou. There is a an application within Visibility - TobRotatedDeviceIndependentImageApp that adds three methods to  CgDeviceIndependentImage.

tobRotated180, tobRotated270 and tobRotated90.

We use these when printing landscape pages in a print run - we actually only print portrait pages so we rotate all landscape pages accordingly

David

On Monday, December 17, 2018 at 1:36:25 PM UTC, Louis LaBrunda wrote:

Hi Norbert,

Thanks for checking this.  So, I reinvented something old.  Still, not bad, as I couldn't find anything (not that my search was exhaustive) that said this is the way rotation is done.

Lou

On Monday, December 17, 2018 at 2:28:41 AM UTC-5, Norbert Schlemmer wrote:

Hi Lou

Does anyone know if I have invented something new or just reinvented something old?

Spoken to a colleague from the  TU Wien (Vienna):

"No, this is the standard way to do it. See any image processing book like  <a href="http://szeliski.org/Book/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fszeliski.org%2FBook%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEFSBnY7awLxMlTGnRZNSM0kSItpA&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fszeliski.org%2FBook%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEFSBnY7awLxMlTGnRZNSM0kSItpA&#39;;return true;">http://szeliski.org/Book/

Regards

Norbert

Lou,

One other thing you might experiment with involves how to present "partial pixels". e.g. If the ideal vector graphic would give 30% of a pixel, see what happens if you fill it with a pixel of 30% saturation.

This might yield an "anti-aliasing" effect and make the non-cardinal rotation angles look smoother. It may also be more work than is worth your time and effort.

I'm pretty happy with the results of a rotation.  The rotated clock hands look good but they may look even better with your idea but I also doubt it is worth the effort.

When I rotate regular pictures (photos) they look as good as any rotation I have seen in image manipulation programs.

Lou

On Wednesday, December 19, 2018 at 1:36:31 PM UTC-5, Richard Sargent wrote:

Lou,

One other thing you might experiment with involves how to present "partial pixels". e.g. If the ideal vector graphic would give 30% of a pixel, see what happens if you fill it with a pixel of 30% saturation.

This might yield an "anti-aliasing" effect and make the non-cardinal rotation angles look smoother. It may also be more work than is worth your time and effort.

On Tuesday, December 18, 2018 at 5:39:08 AM UTC-8, Louis LaBrunda wrote:

Hi Dave,

I know about Visibility and these methods.  As their names imply, they only rotate in 90 degree increments.  I needed to rotate bu any amount.  This is more complicated as the math requires trigonometric functions.  No big deal, just a little more complicated.  The Visibility also seem to use my first thought of taking a pixel, calculating where it goes and putting it there.  At other than 90 degree angles, that leaves gaps.  My first try to fix the gaps was to write code to dilate and then erode the image.  For the simple images I needed, that worked fine.

I thought about the problem more and realized that if I went over every point in the new image and calculated where it came from, that, that would result in a new image with out gaps.  The rotation code I had already written was easily modified to do the rotation this way.  That worked great and eliminated the need for the dilate and then erode filter code.  I started this post to learn if I had invented something new or reinvented something old.  It seems it is the later.

Lou

On Tuesday, December 18, 2018 at 6:32:39 AM UTC-5, Totally Objects wrote:

Lou. There is a an application within Visibility - TobRotatedDeviceIndependentImageApp that adds three methods to  CgDeviceIndependentImage.

tobRotated180, tobRotated270 and tobRotated90.

We use these when printing landscape pages in a print run - we actually only print portrait pages so we rotate all landscape pages accordingly

David

On Monday, December 17, 2018 at 1:36:25 PM UTC, Louis LaBrunda wrote:

Hi Norbert,

Thanks for checking this.  So, I reinvented something old.  Still, not bad, as I couldn't find anything (not that my search was exhaustive) that said this is the way rotation is done.

Lou

On Monday, December 17, 2018 at 2:28:41 AM UTC-5, Norbert Schlemmer wrote:

Hi Lou

Does anyone know if I have invented something new or just reinvented something old?

Spoken to a colleague from the  TU Wien (Vienna):

"No, this is the standard way to do it. See any image processing book like  <a href="http://szeliski.org/Book/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fszeliski.org%2FBook%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEFSBnY7awLxMlTGnRZNSM0kSItpA&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fszeliski.org%2FBook%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEFSBnY7awLxMlTGnRZNSM0kSItpA&#39;;return true;">http://szeliski.org/Book/

Regards

Norbert