Hi.
I working on display driver and I got problem.
I get pixels from two SURFOBJ and I want to compare its’ pixels. When both
SURFOBJ->iBitmapFormat are the same, then that’s not cause any problems.
But I don’t know how to compare them if I get different iBitmapFormats, for
example BMF_24BPP and BMF_16BPP.
I get two pixels and I just want to know are their color is the same or not.
Could anyone can suggest any solution?
User5 wrote:
Hi.
I working on display driver and I got problem.
I get pixels from two SURFOBJ and I want to compare its’ pixels. When both
SURFOBJ->iBitmapFormat are the same, then that’s not cause any problems.
But I don’t know how to compare them if I get different iBitmapFormats, for
example BMF_24BPP and BMF_16BPP.
I get two pixels and I just want to know are their color is the same or not.
Could anyone can suggest any solution?
I am incredibly torn by this question. On one hand, this is an
absolutely trivial problem, and you shouldn’t be working on a display
driver if you cannot figure out how to solve this on your own. On the
other hand, my innate need to answer all technical questions will not
allow me to leave it at that.
Pixels consist of R, G, and B. Two pixels are the same color if their
R, G, and B values are the same. Remember to think about rounding
issues in your particular case, since the fields are different widths.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Yes. I understand that pixel consist of R, G, and B. But If I take for
example BMF_8BPP (one bit per pixel)pixel, then to calculate the R, G, and B
of the pixel I need to use pallete.
So I would like to know is there any standard function/method which I could
use to calculate R, G, and B from pixel of any format? Or I need to write
for every format own function, that will return R, G, and B from bytes.
User5 wrote:
Yes. I understand that pixel consist of R, G, and B. But If I take for
example BMF_8BPP (one bit per pixel)pixel, then to calculate the R, G, and B
of the pixel I need to use pallete.
So I would like to know is there any standard function/method which I could
use to calculate R, G, and B from pixel of any format? Or I need to write
for every format own function, that will return R, G, and B from bytes.
Nope, you have to do it yourself. That’s just not a task that the
typical display driver ever needs.
Be careful with BMF_16BPP. You need to figure out whether it is 5:6:5
or 5:5:5.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of User5
Sent: 19 March 2008 17:30
To: Windows System Software Devs Interest List
Subject: [ntdev] Display Driver, compare two pixelsHi.
I working on display driver and I got problem.
I get pixels from two SURFOBJ and I want to compare its’
pixels. When both
SURFOBJ->iBitmapFormat are the same, then that’s not cause
any problems.
But I don’t know how to compare them if I get different
iBitmapFormats, for example BMF_24BPP and BMF_16BPP.
I get two pixels and I just want to know are their color is
the same or not.
Could anyone can suggest any solution?
You might want to remind us what you’re really trying to achieve. There
must be an easier way!
Tim Green
Development Engineer
DisplayLink (UK) Limited
Hmm. And how can I define, that it is 5:6:5 or 5:5:5 then?
It’s possible, that I can get 5:6:5 and 5:5:5? Or I can get only one of
them?
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> User5 wrote:
>> Yes. I understand that pixel consist of R, G, and B. But If I take for
>> example BMF_8BPP (one bit per pixel)pixel, then to calculate the R, G,
>> and B of the pixel I need to use pallete.
>> So I would like to know is there any standard function/method which I
>> could use to calculate R, G, and B from pixel of any format? Or I need to
>> write for every format own function, that will return R, G, and B from
>> bytes.
>
> Nope, you have to do it yourself. That’s just not a task that the typical
> display driver ever needs.
>
> Be careful with BMF_16BPP. You need to figure out whether it is 5:6:5 or
> 5:5:5.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
User5 wrote:
Hmm. And how can I define, that it is 5:6:5 or 5:5:5 then?
It’s possible, that I can get 5:6:5 and 5:5:5? Or I can get only one of
them?
Where are you getting these bitmaps? A standard 16-bit DIB in user-mode
terms is 5:5:5, but if a driver supports both formats, will get back
whatever format it reported to GDI.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> Where are you getting these bitmaps?
From DrvCopyBits, psoDst and psoSrc.
but if a driver supports both formats, will get back whatever format it
reported to GDI.
Where I can find this information?
User5 wrote:
> Where are you getting these bitmaps?
>
From DrvCopyBits, psoDst and psoSrc.> but if a driver supports both formats, will get back whatever format it
> reported to GDI.
>
Where I can find this information?
If your driver reported to GDI that it was a 16-bit device, then your
ppdev includes an flRed field that shows the position of the red bits.
For 5:5:5, that will be 0x7e00. For 5:6:5, that will be 0xf800. Again,
this is something that your driver told Windows, so it is up to you to
track this information.
If you did not report that you are a 16-bit device, then you should only
be getting standard DIB surfaces, and the standard 16-bit DIB is 5:5:5.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thank you for your answers.
I want ask one more question about surface pixels.
If I get psoDst with 24bit depth pixels and psoSrc with 32bit depth pixels,
how can I compare these pixels? I mean how can I calculate 3 channel pixel
color from 4 channel pixel?
User5 wrote:
Thank you for your answers.
I want ask one more question about surface pixels.
If I get psoDst with 24bit depth pixels and psoSrc with 32bit depth pixels,
how can I compare these pixels? I mean how can I calculate 3 channel pixel
color from 4 channel pixel?
Unless your surface supports alpha, only 3 of the 4 bytes in a 32-bit
surface are used.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
But what about alpha channel?
I get 3 byte pixel and 4 byte pixel and how can I compare them?
I assume that when system is applying new 4 byte pixel to 3 byte, it
calculates what 3 byte color pixel will be in that place.
So, I think I need to do the same calculation to know what pixel there will
be and then compare it with old one.
If I think in right way, how can I do this?
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> User5 wrote:
>> Thank you for your answers.
>> I want ask one more question about surface pixels.
>> If I get psoDst with 24bit depth pixels and psoSrc with 32bit depth
>> pixels, how can I compare these pixels? I mean how can I calculate 3
>> channel pixel color from 4 channel pixel?
>>
>
> Unless your surface supports alpha, only 3 of the 4 bytes in a 32-bit
> surface are used.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
User5 wrote:
But what about alpha channel?
I get 3 byte pixel and 4 byte pixel and how can I compare them?
I assume that when system is applying new 4 byte pixel to 3 byte, it
calculates what 3 byte color pixel will be in that place.
So, I think I need to do the same calculation to know what pixel there will
be and then compare it with old one.
If I think in right way, how can I do this?
Where do you expect to get surfaces with an alpha channel? There are
only two cases where you will get such a thing. One is if you support
DrvAlphaBlend, in which case the source surface can have pre-multiplied
alpha. The other is if your device-managed surface supports alpha, in
which case you can get DrvCopyBits calls to copy into and out of your
surface.
Remember, however, in all these cases the 32-bit pixel is either 0RGB or
ARGB. You should certainly be able to figure out how to compare that to
a 24-bit pixel containing RGB.
Why are you comparing pixels to begin with? What are you really doing?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.