ImageLibEx library

Byak@ said:

How can i rotate image for some degrees?for example 37 degrees?

Click to expand...

Version 1.1 posted with new method BitmapEx.Rotate which rotates a bitmap an arbitrary number of degrees. Note that it you want to merge the source for a device app you need to put a SIP(False) statement in your App_Start if you do not already use SIP else where. This forces the Basic4ppc to reference a .NET assembly that itf would not otherwise do and that is required for merging. This need will be removed with the next version of Basic4ppc.

ooops)big thanks agraham!

Rotate

Hi agraham,
I tested the new features and especially ROTATE works very good and fast in steps of 90° (about 150 msec for an image with 240 x 240 pixels) on my HTC. But 90° is a little too much for “Course Up” with my moving map system. The maximum deviation is 45°. When I rotate the map with the raw heading it takes up to 1800 msec and this is too slow. Is it possible to optimize the rotation for steps of e.g. 30° or 45°. May be we can (you can) replace the trigonometric functions with a constant and this will be much faster??
BTW: Using ROTATE clock- and counterclockwise would be unbelievable!

wolfgang said:

replace the trigonometric functions with a constant

Click to expand...

I already did. It was reasonably optimised before but now I have moved as much out of the main loop as I can. Try this modified library and post here how it goes. It may be a little improved but this is as fast as it is going to get in a .NET library unless I can think of a better algorithm - and I doubt that!

New version

thank you. Can you please upload the cs files as well because I don't develop on the device.

wolfgang said:

thank you. Can you please upload the cs files as well because I don't develop on the device.

Click to expand...

Just copy ImageLibExDevice.dll to your device with your compiled app. I'll sort out cs files and help once I have determined what is going in the next release.

Test

Hi,
first off all: congratulations!
Tested on HTC Cruise 3650 WM 6.0 Pro (Qualcomm® MSM7200™, 400MHz). Image size 240 x 240 pixels (bmp or gif doesn’t matter).
90°, 180° and 270° ~ 130 msec
5° ~ 400 msec
45° ~ 600 msec (45° is the slowest)
That’s very cloth to perfect. Now I have to optimize my code. Thanks’ again.

Hi,
Rotate(180,cWhite) and Flip create a mirror image!? Flip may be correct but not Rotate. This happens on desktop and device with both versions.

wolfgang said:

Flip may be correct but not Rotate.

Click to expand...

Flip is correct but Rotate 180 isn't. Sorry, bad attempt at optimisation . I'll soon release version 1.2 with this corrected, all the rotations slightly more optimised and a couple of other changes and additions.

Wolfgang. Please check this interim version out before I finalise the next release. I have fixed the rotate and added a new rotate method, Rotate180.

agraham said:

Wolfgang. Please check this interim version out before I finalise the next release. I have fixed the rotate and added a new rotate method, Rotate180.

Click to expand...

For sure and it works fine for me.
Please have a look at the quality of the rotated image. Test software included. Thanks to dz too.

Edit: The orange box displays the calculation time in [msec]

wolfgang said:

Please have a look at the quality of the rotated image.

Click to expand...

You can't have speed and quality. I concentrated on speed in the original rotate. That meant calculating for each pixel in the rotated image the nearest pixel in the old image and copying that. In the inner loop of the algorithm, where most time is spent, when optimised that took two integer multiplications, two integer additions, two integer subtractions and three byte fetches and three byte stores, one for each colour.

In the interim library attached the old Rotate is renamed RotateFast and a new RotateHQ method is included. This is a High Quality rotate that seems as good as Paint Shop Pro X2 can manage. It calculates where on the old image each new pixel should be taken from. It has to use floating point for this as we are now dealing with sub-pixel values. The new pixel will not usually "land" completely on an old pixel but on a point surrounded by four old pixels. The relative contribution of each of those four pixels for each colour is calculated and a new average pixel is generated. In the inner loop this now needs eighteen floating point multiplications, about eighteen floating point additions or subtractions, twelve byte fetches and three byte stores. This is obviously a lot slower that the nearest pixel algorithm, especially as devices don't have floating point hardware and have to do floating point sums the hard way. Try it. It produces a very nice result but takes between 2.4 and 3.2 seconds on my HTC Diamond as against 290 to 340 milliseconds for the fast version all in QVGA mode. I haven't looked at optimising the HQ version yet but there won't be that much improvment as all the work has to be done in the inner loop, little of it can be pre-calculated.

agraham said:

You can't have speed and quality.

Click to expand...

I can’t agree with you because you gave us both, speed and quality and that’s perfect. I’m not the only one who will use this lib. In my GPS app all calculations and map handlings must be done within a second and this was the problem. Others will use this lib on the desktop without a speed problem and get a perfect quality now.
I modified the test software: angels in steps of 5° will be rotated with RotateFast and in steps of 10° with RotateHQ.
Thank you again!!!

Version 1.2 now posted in the initial post of this thread with updated help and sources for merging.

The original BitmapEx.Rotate is renamed to RotateFast and is optimised for higher speed. A new BitmapEx.RotateHQ is much slower but gives higher quality results. A new BitmapEx.Rotate180 is provided to rotate a bitmap 180 degrees and BitmapEx.Clone is added to provide a copy of a bitmap.

very big thanks Agraham!

Hi Andrew
I think I found a bug?
When you want to add a image to a form
you select the file name, if it is in a different directory, it copies to you app folder and works fine.
But if the file is in the app directory it gives "An Error occured - error loadinig image"
but then again i may be doing someting stupid
Thanks
Friedrich

Softselect said:

Hi Andrew
I think I found a bug?
When you want to add a image to a form
you select the file name, if it is in a different directory, it copies to you app folder and works fine.
But if the file is in the app directory it gives "An Error occured - error loadinig image"
but then again i may be doing someting stupid
Thanks
Friedrich

Click to expand...

Whatever is happening is nothing to do with ImageLibEx as you are adding the image to an image control in the Designer which then loaded by Basic4ppc at runtime. You haven't included an image but if I put an image called Softselect.bmp in the app directory then run the program it loads fine for me

Hi Andrew,
Yes, now reload as if you loaded the wrong image from the app directory
it seems to work the first time, but not there after.
from a different directory so that it copies the file work well.
thanks Friedrich
Edit:
I am using V6.5

Softselect said:

Yes, now reload as if you loaded the wrong image from the app directoryit seems to work the first time, but not there after.

Click to expand...

I am sorry but I don't understand what you mean by "reload as if ..." Whatever it is it is nothing to do with ImageLibEx.

I mean if you load the image, then see it is the wrong one and try to load another image into the imagebox form the app direrctory.
but i should perhaps report it to Erel as part of Basaic4ppc errors
Thanks for your time
Friedrich