Hello gents.
I have an application under development and I need to rotate an image for an angle of -40 to 40 dgs. I found something on the web,but it is too difficult at this time for me...
http://www.codeguru.com/cpp/g-m/bitmap/imagemanipulation/article.php/c10677/
All I need is a rotated bitmap with dimensions of 250x250pix,same as source.
I don't need the corners,because it is actually rounded bitmap with black corners.
All I need is a void function,which rotates source bitmap to destination one.
I attached also my image,which I want to rotate.
Can anybody help me with this please?
The easiest, simplest and fastest method is to use a drawing program on the PC to create a series of bitmap images already rotated to the desired angle.
Do you really need all 81 images, 1 degree apart, or will a 5 degree increment suffice? Your call, the fewer the simpler.
Store the images in the resource file and draw them to the screen when required.
In this case IDB_BITMAP1 will be the resource ID of the image you require.
If you arrange for all the resource ID's to be consecutive values they can be selected using (IDB_BASE + offset_integer_variable)
To draw it at position x,y
Code:
HBITMAP hbitmap;
hdc=GetDC(hWnd);
hdcMem=CreateCompatibleDC(hdc);
hbitmap=LoadBitmap(hInstance,MAKEINTRESOURCE(IDB_BITMAP1));
SelectObject(hdcMem,hbitmap);
BitBlt(hdc,x,y,250,250,hdcMem,0,0,SRCCOPY);
DeleteDC(hdcMem);
ReleaseDC(hWnd,hdc);
To rotate the image by code can be done, but as you say the code gets pretty complicated and also has a hit on program performance.
Sometimes less is more.
Just a bit late,but after all.
This method I am using normally,but it limits my needs.
The resource image I do need 250x250 pix, X162 in my app)2 rotating images) that means image with dimensions of 2500x4250,that is too much even for Snapdragons and it simply doesn't load that. Therefore I was forced to reduce base resolution to 125x125,but some people reports also problems.
Check out this thread:
http://forum.xda-developers.com/showthread.php?t=682330
Another approach, but it still needs a bit of work and won't look quite as good, (although the more work you put into it, the better it will look), is to draw the image using the GDI drawing functions, in effect turning it into a vector image. Each change in angle would clear the area, then redraw the image. It does not need any memory or resources, merely CPU power to draw it, but GDI drawing is extremely fast.
Another advantage of this method is that it can be scaled to any image size.
The start/end points of lines, central points of circles etc. of each shape can then be rotated round the centre of the image by the angle required, using:
x'= x*Cos(θ)-y*Sin(θ)
y'= x*Sin(θ)+y*Cos(θ)
Where x and y are the distances relative to the centre of the image. Remember that θ is in radians.
In a normal x,y coordinate system (x,y math function graphs etc.) positive values of θ will result in an anticlockwise rotation. In the screen coordinate system 0,0 is the top left of the screen not the bottom left. Y coordinates are in effect inverted, so positive values of θ will result in a clockwise rotation.
You won't be able to use rectangles, as RECT structures and methods that operate on them, only work with horizontally and vertically aligned blocks. You would have to use polygons instead. If you are calculating the next position based on the previous position, as shown in the code below, the values must be held as double, and converted to integer points before drawing them, or the progressive rounding down, will result in the image being drawn progressively smaller. An interesting effect, but not quite what you really want.
To prove this works have a look at the attached, an example of rotating a square.....
Code:
double ptsx[4],ptsy[4];
double st,ct;
case WM_PAINT:
hdc = BeginPaint(hWnd, &ps);
ptsx[0]=ptsy[0]=ptsy[1]=ptsx[3]=50;
ptsx[1]=ptsx[2]=ptsy[2]=ptsy[3]=-50;
st=sin(0.1);
ct=cos(0.1);
GetWindowRect(hWnd, &rt);
GetWindowRect(g_hWndMenuBar,&rtMenu);
mx=(rt.right-rt.left)/2;
my=(rtMenu.top-rt.top)/2;
SelectObject(hdc,GetStockObject(BLACK_PEN));
for(j=0;j<4;j++)
{
MoveToEx(hdc,mx+(int)ptsx[0],my+(int)ptsy[0],NULL);
LineTo(hdc,mx+(int)ptsx[1],my+(int)ptsy[1]);
LineTo(hdc,mx+(int)ptsx[2],my+(int)ptsy[2]);
LineTo(hdc,mx+(int)ptsx[3],my+(int)ptsy[3]);
LineTo(hdc,mx+(int)ptsx[0],my+(int)ptsy[0]);
for(i=0;i<4;i++)
{
x=ptsx[i]*ct - ptsy[i]*st;
y=ptsx[i]*st + ptsy[i]*ct;
ptsx[i]=x;
ptsy[i]=y;
}
}
EndPaint(hWnd, &ps);
break;
There seems to be very little actual documentation on the various eInk update modes.
Most of the information seems to have been extracted from working code.
Some of that code does not seem to be optimal in any case.
I'd like to start this thread on a discussion of the update modes.
You can look at all the code posted, but the bottom line is that eInk mode is configured by passing six discrete pieces of information to the EPD driver.
These six pieces may be wrapped up into a single static entity.
Name of entity requesting change (for logging purposes only)
Region, one of enumRegion[] (Region 4-7)
A rectangle, normally {0, 0, 600, 800}
Wave, one of enumWave[] (GC, GU, DU, A2, GL16, AUTO)
Mode, one of enumMode[] (INACTIVE, ACTIVE, ONESHOT, CLEAR, ACTIVE_ALL, ONESHOT_ALL, CLEAR_ALL)
Threshold, an int 1-15, only applies to A2 mode
A2 is the one bit, fast drawing method. It leaves ghosting behind.
In some applications, you would like to enable faster scrolling in A2 mode and then have it revert to "normal" upon completion.
I have an application with a full screen scroll.
After experimenting with the values, these two configs seem to do the job nicely.
Code:
configA2Enter = makeConfig(rpc, waveEnums[WAVE_A2], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], THRESHOLD);
configA2Exit = makeConfig(rpc, waveEnums[WAVE_AUTO], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], 0);
No user intervention is necessary, it scrolls quickly and redraws a clean image when done.
(A view.invalidate() is necessary after you invoke configA2Exit)
Does anybody have any further insight into these values or suggestions for improving them?
Some additional information on the A2 ("no refresh", 1 bit) mode.
Some of the other modes can be selectively applied to portions of the screen.
The A2 mode may only be applied to the entire screen.
The threshold value, which some may construe as "brightness" or "contrast"
is the cutoff threshold between black and white of the original image.
A value of 1 will only generate black in the darkest areas of the original image.
A value of 15 will only generate white in the whitest areas of the original image.
That is, 1 will give you a light image, 15 a dark image.
Renate NST said:
Some additional information on the A2 ("no refresh", 1 bit) mode.
Some of the other modes can be selectively applied to portions of the screen.
The A2 mode may only be applied to the entire screen.
The threshold value, which some may construe as "brightness" or "contrast"
is the cutoff threshold between black and white of the original image.
A value of 1 will only generate black in the darkest areas of the original image.
A value of 15 will only generate white in the whitest areas of the original image.
That is, 1 will give you a dark image, 15 a light image.
Click to expand...
Click to collapse
Nice find! I didn't know that was a B/W threshold. But I think you meant "1 gives a light image and 15 a dark image".
I've just tried using this in NoRefreshToggle, but the result was not as good as before. The image is much more just solid black and white because you can't see the dither patterns that represent grey (they appear only at very specific white levels, which would be nice to tweak too).
What I actually use for "contrast" adjustment in NoRefreshToggle is a different approach. Using a fixed threshold of 14 (dark image), I've managed to lower the black level (turning it more greyish) to achieve a smaller color range. This way, the dither patterns appear more often. However, my technique to achieve this effect is not so elegant: I overlay the entire screen with a semi-transparent white pane. This has the inconvenient of controlling the pane visibility: whenever A2 mode is turned off (by user or system), I need to hide the pane View.
If I could temporarily avoid the automatic changing of screen modes by the system, this would be much simpler. I've had no success at this issue so far.
marspeople said:
I think you meant "1 gives a light image and 15 a dark image".
Click to expand...
Click to collapse
Yup, good catch. The preceding two sentences were correct. I edited the third.
I have a demo panning grayscales. It's easy to see where the threshold is occurring. Shown below.
Oh! I did see something about the dither modes.
They would certainly be useful for video, less so for text.
I think a system-wide use of A2 would be a bit counterproductive.
The fonts look better with 16 shades.
The best use would be to have browsers and viewers use A2 for panning and zooming.
And another thing:
I don't know how you are getting the dither in there, but since you are doing an overlay anyway,
maybe you should try a halftone screen approach to see how it would work.
The simplest halftone screen would be a checkerboard with two different transparencies.
That wouldn't sacrifice too much resolution.
Renate NST said:
I think a system-wide use of A2 would be a bit counterproductive.
Click to expand...
Click to collapse
i seems to me that n-r mode would be much more usefull if would could regulate when its on a and when off. Its quite pain running the app again and again. it seems to me that quicker reaction is much better than nicer pictures in average use - pdf reading, browsing, video, managing system...
marspeople said:
I've just tried using this in NoRefreshToggle, but the result was not as good as before. The image is much more just solid black and white because you can't see the dither patterns that represent grey (they appear only at very specific white levels, which would be nice to tweak too)
Click to expand...
Click to collapse
I don't think the dithering can be 'tweaked' as such. It's caused by the reduction of 24-bit color images to the 16-bit colorspace of the OS. Dithering is performed by the graphics hardware to prevent obvious colour banding, and there's no OpenGL functions to control dithering parameters.
The A2 mode seems to choose a threshold value for black in the 16-bit colorspace. Values above this are white. In order to obtain black and white dithering we have to pick values in the 24-bit colorspace which all lie in the same 16-bit band.
The easiest way I've found is to keep the R and G values at 255 and vary the B value. I think the default threshold lies at 255,255,198. If you start at that and increase the B value you get 7 dithered grey shades before you reach white.
Guys, as far as i know, eink display is build of tiny capsules, much smaller that one pixel is, and a chip is joining them into pixels. So mayby there is a way to divide single pixel into 2 or even 4? It is much much work, but it would make us easier draw some tones of monochrome? Example: to get dark gray, instead of displaying one of five black pixels white, we can make one's "subpixels" 3/4 black, 1/4 white.
Does it make sense/do you get it?
Renate NST said:
I think a system-wide use of A2 would be a bit counterproductive.
The fonts look better with 16 shades.
The best use would be to have browsers and viewers use A2 for panning and zooming.
Click to expand...
Click to collapse
I agree with you. But having temporary exclusive control of A2 mode would make my application more efficient. I don't intend to use A2 system-wide.
Renate NST said:
And another thing:
I don't know how you are getting the dither in there, but since you are doing an overlay anyway,
maybe you should try a halftone screen approach to see how it would work.
The simplest halftone screen would be a checkerboard with two different transparencies.
That wouldn't sacrifice too much resolution.
Click to expand...
Click to collapse
I just tried this but I've got nothing more than a simply darker and checkered image. I don't understand how it would be better.
marspeople said:
I don't understand how it would be better.
Click to expand...
Click to collapse
Well, halftone screens have been around forever.
Think of it this way, it would give you two different thresholds.
With a bigger pattern you would get more thresholds but a coarser pattern.
That is always the way with dithering or halftone.
Probably a screen would not work well with an underlying dither.
A useful observation from http://forum.xda-developers.com/showthread.php?t=1502723&page=11 is that by listening to the screen you can hear screen activity.
After a quick test I suspect ONESHOT mode allows the screen to enter a power saving mode (in which the screen is completely silent) after a few hundred ms of inactivity, while ACTIVE prevents it. No idea whether there are other issues involved.
The native Reader.apk uses GU, ONESHOT_ALL when turning pages.
Every 6th page it uses GC, ONESHOT_ALL.
In an overnight test with the nook screensaver / lock screen mode inhibited by my application and no screen updates, I obtained power consumption of 0.75% / hour with ONESHOT mode. In a previous test with ACTIVE mode I got ~7% / hour with the same scenario(!)
With fast screen updates of ~ 1Hz ONESHOT does not appear to give any power saving benefit over ACTIVE mode, and a quiet hiss can be heard from the screen at all times in both modes at this refresh rate. I think this indicates the ONESHOT mode allows the screen to enter a power saving mode after a period of inactivity.
Neither of these were scientific tests but I strongly suggest trying ONESHOT mode in favour of ACTIVE whenever using A2 mode.
Well, there must be some benefit sometime to the ACTIVE mode or they wouldn't have it.
It's hard to differentiate the different modes, but it seem that ACTIVE responds quicker with less delay.
I switch to ACTIVE_ALL, A2 for panning and switch back to ONESHOT_ALL, AUTO afterwards.
(I don't use full-time A2).
See my demo of panning: http://forum.xda-developers.com/showthread.php?t=1563645
I'm running about 7%/hour drain. My Nook is not suspending when I do a simple power button click. I don't know why.
A few folks seem to be using EpdController in a useful manner.
Their use of Java reflection is clever, but it's not supposed to be that difficult.
I wrote a Java stub (basically declarations) for EpdController and wrapped it in a jar.
If you just put this jar in your compilation classpath with your normal android.jar
then you will be able to use the EpdController without all the fuss and muss.
For example, in my latest (unreleased) version of UsbMode I want the blinker to go on and off cleanly:
Code:
EpdController.setRegion("UsbMode", EpdController.Region.APP_3, blinker, EpdController.Wave.DU);
That's it, one line, no initialization.
The EpdController class was designed to handle such trivial uses.
Note: This jar itself has no functionality, all the method bodies are {}.
You will have to import android.hardware.EpdController
The 1.2 update uses a different EpdController and has a new EpdRegionParams.
This may or may not break code written for previous versions.
The best way to write code to use EpdController is to have it detect if there is no Epd
(i.e. for other devices), the old version or the new version.
Wrap a try/catch around a Class.forName("android.hardware.EpdController").
Wrap a try/catch around a Class.forName("android.hardware.EpdRegionParams").
The new epd.jar in the signature will allow you to compile without using redirection both the old and the new.
For details on the changes, see: http://forum.xda-developers.com/showpost.php?p=35390192&postcount=8
Bump & additional info.
By experimenting and reading documentation for other eInk controllers I've figured out the following:
Controllers support different algorithms for updating the pixels depending on the precision of the gray scale required and the compensation for previous ghosting.
On the Nook, we have the choice of waveform modes:
GC
GU (gray update)
DU (direct update)
A2
GL16
AUTO (auto selection of algorithm)
The screen can be divided up into regions where different algorithms may be used.
Some controllers support 15 regions, ours supports 8.
4 of these regions are earmarked for system usage, specifically:
Toast (popups)
Keyboard (soft keyboard layout)
Dialog (popups)
Overlay
The remaining 4 regions are left for the user.
Note: "HwRegion" is an enum for the complete 8 regions, "Region" is an enum for the 4 user regions.
An example: In my audio recorder I have two regions set aside for the VU bar graphs.
By setting these two regions to DU I get rid of update clutter and the response is quicker.
Currently, the EpdController in the Nook only operates with portrait coordinates.
If you wish to use this while in landscape mode you will have to rotate the coordinates first yourself.
It's sometimes hard to see exactly what/if some EPD setting is doing.
A good way to check it is to set a region for one half the width of whatever active graphic element you are trying to improve.
The difference can be very clear.
Renate NST said:
There seems to be very little actual documentation on the various eInk update modes.
Most of the information seems to have been extracted from working code.
Some of that code does not seem to be optimal in any case.
I'd like to start this thread on a discussion of the update modes.
You can look at all the code posted, but the bottom line is that eInk mode is configured by passing six discrete pieces of information to the EPD driver.
These six pieces may be wrapped up into a single static entity.
Name of entity requesting change (for logging purposes only)
Region, one of enumRegion[] (Region 4-7)
A rectangle, normally {0, 0, 600, 800}
Wave, one of enumWave[] (GC, GU, DU, A2, GL16, AUTO)
Mode, one of enumMode[] (INACTIVE, ACTIVE, ONESHOT, CLEAR, ACTIVE_ALL, ONESHOT_ALL, CLEAR_ALL)
Threshold, an int 1-15, only applies to A2 mode
A2 is the one bit, fast drawing method. It leaves ghosting behind.
In some applications, you would like to enable faster scrolling in A2 mode and then have it revert to "normal" upon completion.
I have an application with a full screen scroll.
After experimenting with the values, these two configs seem to do the job nicely.
Code:
configA2Enter = makeConfig(rpc, waveEnums[WAVE_A2], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], THRESHOLD);
configA2Exit = makeConfig(rpc, waveEnums[WAVE_AUTO], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], 0);
No user intervention is necessary, it scrolls quickly and redraws a clean image when done.
(A view.invalidate() is necessary after you invoke configA2Exit)
Does anybody have any further insight into these values or suggestions for improving them?
Click to expand...
Click to collapse
Excellent work! Do you happen to understand/can write up what the various fast mode/no refresh hacks do/how they use these different modes?
I've had X 'running' on my nook but only by triggering a full refresh every few seconds, and wondered how I could be more selective.
My reading of Norefresh was that it was doing something like parsing android log structures for areas that have changed.
Is there an easy way to trigger a refresh of part of the display from userspace, preferably directly on the driver or fb?
As for where the dithering is done, my guesswork is this is done by a blob running on the DSP module within the OMAP (which is perhaps the only interesting use of it I've seen).
Dave
Just done some playing writing directly to the entires in /sys/class/graphics/fb0 ; so for example:
echo -n 100,100,200,200,0,14 > epd_area
echo 2 > epd_refresh
causes the square 100,100->200,200 to be refreshed
the 14 being REGION(8)+CLEAR(4)+ONESHOT(2)
the 0 is wvfid+threshold*65536 I think.
I've put some code that runs under X to trigger updates; here (actually the comment is wrong, it's currently using oneshot+clear);
I never managed to get active to work.
http://forum.xda-developers.com/showthread.php?p=42393733#post42393733
Dave
Hi everyone this is my new app and I need some testers...
Remember when we were young we used to imagine drawing shapes in the air by moving hands.. Now this is possible; this app lets you draw a picture or write words simply by moving your hand in the air...
Hold your device face up, hold your touch anywhere on the screen, move your hand in any direction and the movement will be drawn on the screen.
Keep in mind that everytime you start drawing the app will create a virtual drawing field from 90° left to 90° right this is the range you can move your hand in (ie: you can't turn around).
Additional feature: In the app settings you could change the drawing field to +-35° that means you could draw the scene in front of you by moving the device toward the edges of things that you want to draw..
it's about fun and activity, although your drawings may not be that perfect..
Requirements:
# Android 2.3+
# Orientation sensor (compass) available on device.
** the performance of the app depends on speed an quality of the sensor which could differ according to the device model and brand, so the test should focus on performance**
http://www.1mobile.com/airdraw-1508234.html
Just played around with it for a minute or so, your up and down features are working well but only when tilting the device. Your left and rights aren't up to par yet for sure. If you can edit it to make it more reliant on the phones position and not orientation I think you'll have better luck! Great concept!
Sent from my SAMSUNG-SGH-I317 using xda premium
XBearingArmsX said:
Just played around with it for a minute or so, your up and down features are working well but only when tilting the device. Your left and rights aren't up to par yet for sure. If you can edit it to make it more reliant on the phones position and not orientation I think you'll have better luck! Great concept!
Sent from my SAMSUNG-SGH-I317 using xda premium
Click to expand...
Click to collapse
Thanks for your reply,
First of all the device should always be level (ie: not tilted, unless when pressing the "brush" size button (the last button on the right)).
Second, your problem is a little bit weird because whenever the device contains a compass the pointer (circle) on the screen should follow the movement of the device (left, right, up and down), but the problem that may occur on some devices is the latency (slow sensor responsiveness) especially with fast movements.
Third, the device orientation sensor is one of the main sensors that determines the device position, so I don't know what do you mean by "position".
this is a demo about using the app on my galaxy s3:
https://www.youtube.com/watch?v=St63EKIBxAg&feature=youtu.be
could you try again, and describe the problem in more details..(Latency, No/Wrong horizontal/vertical pointer movement, No pointer at all..)
After some tests a problem have appeared on some devices caused by the need to calibrate the magnetic (orientation) sensor which result in an irregular pointer movements..
to check if your magnetic senor (compass) needs calibration:
1- open phone and enter the code: *#0*#
2- press Sensor button
3- on the bottom of the screen there is a black circle with a line in it that represents the orientation.
4- if the line's color is not blue and the number under is less than 3 that means the sensor needs calibration.
5- to calibrate the sensor simply wave your device in 8 pattern https://www.youtube.com/watch?v=AzQSsUsOWJc, continue to do it until the line becomes blue, this mean that the sensor is now calibrated..
** if the device have a cover that have a magnet in it, you should remove that cover **
open the app and check if the problem is solved..