Results 1 to 19 of 19

Thread: Color Depth, GetPixel, and Bit Rot

  1. #1

    Thread Starter
    Lively Member Zero's Avatar
    Join Date
    Feb 2000
    Posts
    101

    Color Depth, GetPixel, and Bit Rot

    I'm using DirectX 7 for this, since I have at least a vauge notion of what I'm doing with it...

    What determines the color depth of a surface? If I load a 24 bit per pixel image into a surface but DirectX is chugging along at 16bpp, will the image be 'scaled back' to 16 bits? Will GetPixel (GetLockedPixel, whatever) return a 16 bit or 24 bit value?

    ~Zero the Inestimable

  2. #2
    Good Ol' Platypus Sastraxi's Avatar
    Join Date
    Jan 2000
    Location
    Ontario, Canada
    Posts
    5,134
    I'm not sure- it may be handled internally as 24-bit and then "scaled back" as you say to 16bpp to display, but I'm not sure. I don't think it does though, because when I load a 256-colour bitmap in a 24bpp environment, palettes don't work. Any other input?
    All contents of the above post that aren't somebody elses are mine, not the property of some media corporation.
    (Just a heads-up)

  3. #3
    Kitten CornedBee's Avatar
    Join Date
    Aug 2001
    Location
    In a microchip!
    Posts
    11,594
    When you lock a surface buffer and then try to directly accesss the memory there (don't know if that works in VB), you must take care of the color depth yourself. There is neither a GetPixel nor a GetLockedPixel function in pure DX (at least not DX6, maybe 7), this must be part of the VB wrapper. I can't help you with this.

    The API GetPixel function always returns a 24-bit value.
    All the buzzt
    CornedBee

    "Writing specifications is like writing a novel. Writing code is like writing poetry."
    - Anonymous, published by Raymond Chen

    Don't PM me with your problems, I scan most of the forums daily. If you do PM me, I will not answer your question.

  4. #4
    Good Ol' Platypus Sastraxi's Avatar
    Join Date
    Jan 2000
    Location
    Ontario, Canada
    Posts
    5,134
    Yes, but if you needed to find out, look at the locked array and divide the X number by the width of the image. Then you will have the bpp of the picture. x8 is the colour depth.
    All contents of the above post that aren't somebody elses are mine, not the property of some media corporation.
    (Just a heads-up)

  5. #5
    Kitten CornedBee's Avatar
    Join Date
    Aug 2001
    Location
    In a microchip!
    Posts
    11,594
    You have the bytes per pixel (bpp is bits per pixel). You have to multiply it with 8 to get the bpp form.

    1: 8 bpp, 256 colors
    2: 16 bpp, 65000 colors
    3: 24 bpp, 16 Mio. colors
    4: 32 bpp, (theoretically) 4 billion colors, only 24 bits used, last is padding
    All the buzzt
    CornedBee

    "Writing specifications is like writing a novel. Writing code is like writing poetry."
    - Anonymous, published by Raymond Chen

    Don't PM me with your problems, I scan most of the forums daily. If you do PM me, I will not answer your question.

  6. #6
    Good Ol' Platypus Sastraxi's Avatar
    Join Date
    Jan 2000
    Location
    Ontario, Canada
    Posts
    5,134
    Yea, thats what I said

    But, the last 8 bits is for the Alpha channel if there is one.
    All contents of the above post that aren't somebody elses are mine, not the property of some media corporation.
    (Just a heads-up)

  7. #7

    Thread Starter
    Lively Member Zero's Avatar
    Join Date
    Feb 2000
    Posts
    101

    ...

    Actually, it's the first 8 bits that are the alpha channel.

    I suppose experimentation is the only way to do it. I was just wondering if I'll have to do extra math on pictures outside the current colordepth (I'm designing a DX driven paint application). Since I have to run windowed I get my colordepths handed to me on a rusty platter by Windows, and there ain't much I can do about it. If the user loads a 24 bit picture but has the display set to 16 bits, I need to know how accurate GetLockedPixel will be with pulling stuff from the surface I put the picture on...

    ~Zero the Inestimable

  8. #8
    Kitten CornedBee's Avatar
    Join Date
    Aug 2001
    Location
    In a microchip!
    Posts
    11,594
    Yes, you have to calculate that yourself.
    But as long as you don't need to convert a 16+ bit bitmap to a 256 color one, it's not that hard.

    When talking bytes and bits, you don't use "first" and "last". You use "high order" and "low order" or "most significant" and "least significant". Actually, the last version is the clearest, because it is independent of little/big endian format.
    All the buzzt
    CornedBee

    "Writing specifications is like writing a novel. Writing code is like writing poetry."
    - Anonymous, published by Raymond Chen

    Don't PM me with your problems, I scan most of the forums daily. If you do PM me, I will not answer your question.

  9. #9
    Good Ol' Platypus Sastraxi's Avatar
    Join Date
    Jan 2000
    Location
    Ontario, Canada
    Posts
    5,134
    Zero, I'm just saying that because it happens to be that way on MY configuration - each computer will vary. It is either ARGB, ABGR, RGBA, BGRA. I believe ARGB is the usual way, in order of most significant bit to least significant bit.

    Happy now?
    All contents of the above post that aren't somebody elses are mine, not the property of some media corporation.
    (Just a heads-up)

  10. #10

    Thread Starter
    Lively Member Zero's Avatar
    Join Date
    Feb 2000
    Posts
    101

    ...

    It varies? Aw, hell...

    ~Zero the Inestimable

  11. #11
    Good Ol' Platypus Sastraxi's Avatar
    Join Date
    Jan 2000
    Location
    Ontario, Canada
    Posts
    5,134
    Well there is a way to detect WHERE they are, using the Bitshifts provided by the Pixel Format. I'm not exactly sure, but it gives you a hex value back and you can find if its the most significant, least significant, or an in-between bit. In this way you can construct where you get certain values from.

    If I can find something, I'll let you know...
    All contents of the above post that aren't somebody elses are mine, not the property of some media corporation.
    (Just a heads-up)

  12. #12
    Zaei
    Guest
    In C++, I usually define my colors:
    Code:
    0xff00ff99
    0xff  00  ff   99
      A    R    G    B
    Z.

  13. #13
    Kitten CornedBee's Avatar
    Join Date
    Aug 2001
    Location
    In a microchip!
    Posts
    11,594
    Yeah, that's the DirectX color format.
    The GDI uses COLORREF which is a hybrid value: FRGB. F is a flag that can be 0 for simple RGB, 1 for an RGB that needs to be mapped to a palette or 2, which means the other bytes are the index in a palette.
    All the buzzt
    CornedBee

    "Writing specifications is like writing a novel. Writing code is like writing poetry."
    - Anonymous, published by Raymond Chen

    Don't PM me with your problems, I scan most of the forums daily. If you do PM me, I will not answer your question.

  14. #14
    transcendental analytic kedaman's Avatar
    Join Date
    Mar 2000
    Location
    0x002F2EA8
    Posts
    7,221
    Originally posted by Zaei
    In C++, I usually define my colors:
    Code:
    0xff00ff99
    0xff  00  ff   99
      A    R    G    B
    Z.
    shouldn't that be
    0x99ff00ff
    Use
    writing software in C++ is like driving rivets into steel beam with a toothpick.
    writing haskell makes your life easier:
    reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
    To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.

  15. #15
    Kitten CornedBee's Avatar
    Join Date
    Aug 2001
    Location
    In a microchip!
    Posts
    11,594
    why should it?
    0xFF is what the DX tutorials use...
    All the buzzt
    CornedBee

    "Writing specifications is like writing a novel. Writing code is like writing poetry."
    - Anonymous, published by Raymond Chen

    Don't PM me with your problems, I scan most of the forums daily. If you do PM me, I will not answer your question.

  16. #16
    Zaei
    Guest
    Yeah, you turned it around, kedaman. Now you have an alpha of 0x99, red of 0xff, green of 0x00, and a blue of 0xff

    Z.

  17. #17
    transcendental analytic kedaman's Avatar
    Join Date
    Mar 2000
    Location
    0x002F2EA8
    Posts
    7,221
    no, if B is the high order byte, it should come first in a hexa decimal notation, etc..
    Code:
    0xff00ff99
      B G R A
    Use
    writing software in C++ is like driving rivets into steel beam with a toothpick.
    writing haskell makes your life easier:
    reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
    To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.

  18. #18
    Kitten CornedBee's Avatar
    Join Date
    Aug 2001
    Location
    In a microchip!
    Posts
    11,594
    But DX format is ARGB, not BGRA
    All the buzzt
    CornedBee

    "Writing specifications is like writing a novel. Writing code is like writing poetry."
    - Anonymous, published by Raymond Chen

    Don't PM me with your problems, I scan most of the forums daily. If you do PM me, I will not answer your question.

  19. #19
    transcendental analytic kedaman's Avatar
    Join Date
    Mar 2000
    Location
    0x002F2EA8
    Posts
    7,221
    ok.. haven't used DX in a while
    Use
    writing software in C++ is like driving rivets into steel beam with a toothpick.
    writing haskell makes your life easier:
    reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
    To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width