Pixel

[jrsmile]

Hi, would you be so kind and explain to me what would be necessary to get raw access to the image captured? i would like to spit out the pixelcolors on the std output. for example g_DXGIManager.SetCaptureSource(CSMonitor1); RECT rcDim; rcDim.left = 1; rcDim.top = 1; rcDim.right = 361; rcDim.bottom = 2; hr = g_DXGIManager.GetOutputBits(pBuf, rcDim); printf(pBuf)

i was able to get some output but could not recognice any pixel colors.

my endgoal would be a list of uniq colors in a known area on a known monitor and how much pixels there are of. so a call of the exe would result in: 0xFF0000,2 0x00FF00,20 0x0000FF,30 0x000000,100 0xFFFFFF,200

Thanks in Advance, JR

[pgurenko]

Hi JR,

After the call to GetOutputBits, pBuf should have the 361*2 integers each representing the actual pixek in BGRA: https://github.com/pgurenko/DXGICaptureSample/blob/9e304f24b5b11bbd1c61a9c1c528693cd2843c5d/DXGICaptureSample/DXGIManager.cpp#L514

You can get an idea on how to access those by looking at the mouse pointer drawing code here: https://github.com/pgurenko/DXGICaptureSample/blob/9e304f24b5b11bbd1c61a9c1c528693cd2843c5d/DXGICaptureSample/DXGIManager.cpp#L634

[jrsmile]

Hi, thanks for pointing me to the correct solution. i came up with this: https://github.com/jrsmile/DXGICaptureSample/blob/master/DXGICaptureSample/DXGICaptureSample.cpp

the first thing i tried was to crop the framebuffer to my desired RECT. as a result it spid out a defect bmp. so i removed the bmp conversion alltogether and went back to fullscreen RECT. now the buffer works. but it adds a lot of overhead during capture.

could you tell me how to solve this?

[jrsmile]

sorry to disturb you again, i have a problem with the above mentioned example. when loosing focus the application hangs and only occasionaly spits out a new line of recorded pixels. is there some kind of thread sleep involved when ithe application is not in foreground?

[pgurenko]

so i removed the bmp conversion alltogether and went back to fullscreen RECT. now the buffer works. but it adds a lot of overhead during capture. could you tell me how to solve this?

Not sure this is the right code for the job then: if you need only part of the screen, probably old goo GDI will work better, this technique is for whole desktop/monitor capture.

sorry to disturb you again, i have a problem with the above mentioned example. when loosing focus the application hangs and only occasionaly spits out a new line of recorded pixels. is there some kind of thread sleep involved when ithe application is not in foreground?

Not sure I understand the case: you only capture once in your code, when does this loosing focus gets place? First idea is process does something heavy and OS just does not give it enough CPU when in background (changing process priority could tell whether it's the case). There is no sleeps in the capture code.