Jump to content

  • Log In with Google      Sign In   
  • Create Account


Win32 - capturing screenshots and odd resolutions


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
10 replies to this topic

#1 SymLinked   Members   -  Reputation: 816

Like
0Likes
Like

Posted 25 June 2012 - 01:34 PM

Hi!

I've implemented a simple screenshot capture method, where I do the following:
  • Get the screen DC by calling GetDC (NULL);
  • Use CreateCompatibleDC () to create a device context.
  • Grab width/height of the screen by calling GetDeviceCaps ().
  • Calling CreateCompatibleBitmap (screenDC, width, height);
  • Calling SelectObject (deviceContext, bitmap);
  • Finally, calling BitBlt (deviceContext, 0, 0, x, y, screenDC, 0, 0, SRCCOPY | CAPTUREBLT); and GetDIBits () to get the data pointer.
This works fine except that it doesn't work in odd resolutions like 1366x768 where everything shows up as white/black lines. Anyone got any ideas what's causing this? Is the data output from GetDIBits() padded in this case or something? It looks like there's an extra byte per channel or something which distorts the image as I'm assuming 32-bit, but that's hardly the case as the image is 32-bit.

Any advice is greatly appreciated!

Sponsor:

#2 frob   Moderators   -  Reputation: 18857

Like
1Likes
Like

Posted 25 June 2012 - 02:46 PM

Read up a little about the bitmap format.

The format has some details that you may have missed.

The data probably IS NOT CONTINUOUS.

Every pixel entry can potentially have some unused space on it; as you noticed only 24 bits are valid but 32 bits are used. Every scan line may potentially have some unused space on it. e.g. The data may have space for 1024 but the window is only 1022 pixels long.

You need to account for both.
Check out my personal indie blog at bryanwagstaff.com.

#3 SymLinked   Members   -  Reputation: 816

Like
0Likes
Like

Posted 25 June 2012 - 03:46 PM

That sounds logical, but how exactly would you detect when this happens? It's definatly not different bitrates, I already account for that - it's something else.
I've Googled and Googled but come up with nothing.

I retrieve the width, height, numBits and format but it looks exactly the same as in all other resolutions.

#4 Martins Mozeiko   Crossbones+   -  Reputation: 1413

Like
0Likes
Like

Posted 25 June 2012 - 05:52 PM

How are you processing lpvBits argument from GetDIBits function?

#5 SymLinked   Members   -  Reputation: 816

Like
0Likes
Like

Posted 26 June 2012 - 01:31 AM

Just a memory copy, which works in all other resolutions I've tested except 1366x768. Even the bitmap header says the size of the lpvBits data is what I expected (ie, 4 * width * height) so I'm not sure how I would be able to read it any differently.

#6 Amr0   Members   -  Reputation: 1030

Like
1Likes
Like

Posted 26 June 2012 - 05:24 AM

Yes the symptoms conform with padding unaccounted for. In addition to per-pixel padding, the BMP format uses per-row padding. You can calculate the number of bytes used per row of pixels like so:
rowSize = DWordAlign( bpp/8 * width );
You may find these useful: Mirror: GDI-based mirror window (src code included), GDI Memory Bitmap

Edited by Amr0, 26 June 2012 - 05:27 AM.


#7 SymLinked   Members   -  Reputation: 816

Like
0Likes
Like

Posted 26 June 2012 - 11:43 AM

Thanks Amr0!

But the return value of DWordAlign with the argument of (32 / 8 * 1366) is the same as the argument so it has no effect.
GDI Memory Bitmap is a very useful resource though, I'll keep poking and see what's different from your implementation!

Thanks again.

Edited by SymLinked, 26 June 2012 - 11:52 AM.


#8 SymLinked   Members   -  Reputation: 816

Like
0Likes
Like

Posted 26 June 2012 - 02:42 PM

If you have 4 bytes per pixel, and are using a 1366 width - everything is already aligned to 4 bytes. It would have been different if it was 3 bytes per pixel but that's not the case here.
I'm still looking for suggestions. (Edit: Fixed. See my last response for solution)

Posted Image

Edited by SymLinked, 26 June 2012 - 03:40 PM.


#9 Bacterius   Crossbones+   -  Reputation: 8158

Like
1Likes
Like

Posted 26 June 2012 - 03:00 PM

Code, please. Without the actual details of how you obtain this result we can't do any better than vaguely theorize on why you aren't getting what you want. The shearing clearly indicates you are getting out of sync with the pixels on a per-row basis, and the color corruption is just weird.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#10 frob   Moderators   -  Reputation: 18857

Like
2Likes
Like

Posted 26 June 2012 - 03:17 PM

The image sheering looks like a textbook example of not accounting for the row length. Each row has a few pixels from the next row, causing the row below it to be shifted a few pixels.
Check out my personal indie blog at bryanwagstaff.com.

#11 SymLinked   Members   -  Reputation: 816

Like
1Likes
Like

Posted 26 June 2012 - 03:38 PM

Thanks Baterius, I was about to do that but figured it out now.

The above mentioned resources are correct and I'll edit my response. The error was my fault and was caused by me assuming FreeImage would just accept my buffer as is, without calling SetPixelColor() on each individual pixel. The latter works which I guess means I have to read up on how FreeImage stores its bitmaps instead.

Sorry for the misinformation on my side. Everything claimed so far was correct, I was just looking in the wrong spot.

Edited by SymLinked, 26 June 2012 - 03:40 PM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS