Introduction
This project came about as the result of a question in one of the newsgroups. Someone was asking about how to write a color-picker.
Far too many times, I've needed a color-picker. I've also needed to capture pieces of images on the screen to put into other programs, such as icons. The problem is that ZoomIn doesn't support most of what I need to do.
What's wrong with Zoomin?
- I have to get the image right the first time. If I don't have it selected properly, I can't nudge it over.
- I have to get the scaling right. Otherwise I might get too much of the image, or not enough.
- Once having gotten the image, I can't select a piece of it.
- Copy-to-clipboard copies the image in the Zoomin window, not the actual pixels that were on the screen..
The original questioner had posed some complicated ways of dealing with the problem, such as using timers and hook functions. These aren't necessary.
This project produces an image much like the one below:
In order to create this, I set the image size, controlled by the spin control at the top, to 64 pixels. I then took the picker tool, 
, and dragged it over the screen until I was over the light bulb in the heading of a page. I wasn't quite where I wanted, so I used the "nudge" arrows to move it around a bit.
While moving around, there is an RGB value displayed at the top right. In addition, the actual R, G and B colors are shown. This represents the actual point where the cursor is placed (although you probably can't see it, there is a little tiny white dot in the middle of the picker tool that represents the cursor hotspot position). The way this is seen on the expanded image is that the dotted square in the center is the hotspot, expanded. The lines extending from the edges are just to make it interesting to find.
The ? key in the middle will display a box around the area that is selected.
The copy icon button, 
, will copy the contents of the selection to the clipboard.
However, there are additional features.
Once the image is captured, moving the mouse over it will put into the RGB display the actual pixel value for the pixel under the mouse.
Clicking and dragging within the image area will select a sub-region. This will then be marked with a selection rectangle. Note that the old rectangle does not disappear until the new one is created. This is deliberate, so you can see the old selection while making a new, larger or smaller, selection.
This is shown in the figure below. Note that this image is smaller. I did that by resizing the dialog. In this example, there is a selection box around the base of the lamp.
What's interesting about this code?
Like most of my examples, this is intended to show some ideas about using Windows and/or MFC. Ideas that are included in this code are:
- Creation of a window DC that covers the entire desktop window.
- Grabbing a piece of the window and saving it as a local bitmap.
- Selecting a piece of that bitmap.
- Rubber-banding selection box.
- Displaying color swatches.
- Copying a bitmap to the clipboard.
- Having a "picker" tool (much like you would recognize from Spy++).
- Noting that you can in some cases interchange cursors and icons, which is what I did here.
- Creating a
CWnd-derived popup window (the implementation of the ? button).
- Having a window that can be created and which will disappear on its own (the ? button's display window).
- The use of the implicit
SetBkMode(OPAQUE) to create lines that are alternating colors, so the line shows up whether the background is light or dark.
- Computing points in logical space and translating them to device space (the array of points used to draw the highlighting square in the first image). Note that the horizontal and vertical lines are actually a "fractional pixel" in logical space, and there is a trick to accomplishing that.
- Owner-draw buttons (those arrow buttons, and the copy button).
There isn't much code here, but the code that is here illustrates several useful techniques.
The views expressed in this essay are those of the author, and in no way represent, nor are they endorsed by, Microsoft.
| You must Sign In to use this message board. |
|
|
 |
|
|
|
|
|
|
|
|
|
|
|
I discovered that it is NOT possible to take screenshots from a MediaPlayer window doing ALT+PRTSCR. I first thought this is a DRM issue, but read somewhere that it is related to some DirectVideo optimization.
Must try out whether your tool works with MediaPlayer windows, too 
--
Affordable Windows-based CMS for only 99 €: try www.zeta-producer.com for free!
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Yeah, the simple reason for this is that windows really doesn't "know" anything about this content - at least on the upper level. Video streams are rendered by copying the data directly into the video memory, so it arrives immediatly on the screen cutting out the middle man of the GDI system. I think if WMP were to implement the WM_PRINTCLIENT message, that would fix the problem. But MS haven't bothered!
Joel Holdsworth
Wanna give me a job this summer?
Check out my online CV and project history[^] - now available in MSWord format![^]
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Yes, it's definately because the video stream is sent and rendered on the card, so doing "alt + printscreen" only attempts to grab the screen capture for that application, which doesn't have the video.
However, if you do a print screen for the entire screen you should be able to get the image then because the graphics card driver should read or flush back into software the image that was pushed to the video card. Most likely it doesn't know to do this if you're just attempting to flush back in from the HDC of the application, rather than the entire desktop (The video being rendered is associated with screen coordinates rather than being "owned" by the application's window itself).
If this zoom tool uses the full screen (desktop) HDC, then most likely it should work and read the entire frame buffer back in from video memory.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
I do use the desktop DC, and I just BitBlt a piece of the bitmap I obtain. It certainly got the "ambience" information.
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
If you want to see something cool, do a performance timer on only the BitBlt command. You'll notice that most of the time if you're dealing with cached software LVB's that it's less than a ms. However, if you're forced to read from the card as such with playing a video or with windowed DX/OGL you'll get a much slower BitBlt such as 9ms, 12ms and even slower depending on usually just the video card and bus but the video driver software can also play into it.
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
|
|
|
Go into the properties of your graphic card, turn the optimisations off (or on lower level), and then you can take your screenshots ...
~RaGE();
|
| Sign In·View Thread·PermaLink | 4.00/5 |
|
|
|
|
|
|
|
|
|
An even easier way is to just run an app that will occupy the overlay surface so that WMP (or any other app) will default to the normal renderer. When you need it to use the overlay again you just quit that app. This way you won't forget to restore the setting in the media player or the video drivers.
I use Karsten Sperling's Alpha[^] which is a great toy-app anyway. 
--
Synetech
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
This is some nice work. It is interesting to see different approaches taken to solve similar problems. For example, there is anoher ZoomIn out there http://www.csc.calpoly.edu/~bfriesen/software/zoomin.shtml[^] enhanced by Brian Friesen that allows you to move about the screen using the cursor keys.
It is an enhanced version of the (probably) original Microsoft ZoomIn utility.
Brian's ZoomIn displays the color values of the pixel the mouse is over in the ZoomIn window.
I have started with Brian's sample and really gone to town on it. In Brian's example for certain and Microsoft's original example (maybe new ones don't have this problem...), you can not drag the selection rectangle over to the second or other monitors in a multiple monitor system, because screen retireval is hard coded to GetDC(NULL) instead of using multiple monitor API. I am still resolving some of the multiple monitor issues.
Anyway, Brian's current example is certainly worth a look, and once I am happy with my example, I will post the information to CodeProject, assuming Brian does not totally object. It would probably be available from his site as well, space and whatever limitations he has permitting.
Brian's ZoomIn does save the zoomed image to the clipboard, rather than the original DC.
Brian's is not meant to be a partial screen capture utility, unlike one of the features of Joseph's enhancement.
Thanks for sharing Joseph 
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Mine was tested on multiple monitors; in fact, the capture example was made on one monitor while the program was running on the other. During testing, I was able to run the program on one monitor and capture images on the other, for either of my two monitors. However, if there are any issues arise with respect to multiple monitors, I'd like to hear about them.
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
I did not observe any issues on a Matrox Millenium G550 running Windows XP with two VGA monitors.
They are set up with different screen resolutions but joined together as a single virtual desktop.
I had your app split across both monitors and the zoomed area it was viewing split across both monitors.
Your program worked fine.
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
 | Nice! 
ThatsAlok | 3:25 17 Jun '05 |
|
|
Great Utility
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
Agree! Up to now, I had to make screen captures with my favorite image processing tool in order to pick up the desired pixel color. This is really a nice tool.
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
|
|
|
Stlan wrote:
I strongly suspect you are the other one...
No need to suspect, I am the other one or REAL ONE
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
|
| Sign In·View Thread·PermaLink | |
|
|
|
|
|
|
