Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. DIBS and "the bits"

DIBS and "the bits"

Scheduled Pinned Locked Moved C / C++ / MFC
helpquestiongraphicstutorial
7 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C Offline
    C Offline
    Chambers
    wrote on last edited by
    #1

    Hi all, I have managed to load/create (as necessary) a 24-bit DIBSection using the means described on this very web site (LR_CREATEDIBSECTION flag in LoadImage and CreateDIBSection), both of which return a HBITMAP. Superb. What I want to do now is "grab" the actual BGR colour values that make up each pixel, and change them to something else such as RGB(0,255,0 - Green, its the easiest example to use). At the moment I am trying to get the bits using a BITMAP structure (returned through GetObject) and its bmBits property. I have also implemented Christians wizardry to convert this pointer to a valid LPBYTE by :

    for (int y=0, y < bm.bmHeight, y++)
    {
    LPBYTE pbSrcRGB = (LPBYTE)&((DWORD*)pDestBits)[y*bm->bmWidth]
    for (int x=0, x < bm.bmWidth, x++)
    {
    pbSrcRGB[0]=0
    pbSrcRGB[1]=255
    pbSrcRGB[2]=0
    pbSrcRGB+=3
    }
    }

    However, the program crashes out after a few laps of the for loops. I have also checked to see whats in pbSrcRGB at position [0] BEFORE assignment and every time it has : 0 '' it is NULL terminated. How is this remedied? BITMAP structure is passed into this function by : &bm and a LPBITMAP structure is then used (as you can see from bm->), so I would have thought that everything was OK from the BITMAP point of view. Also the bitmap starts off black (which I don`t want, thats why I`m changing it all to green), so I assume this is why it reads 0 ''. Also when I check pbSrcRGB[0] to see what it contains AFTER assignment, it reads : 255 'y' (with funny line over the top of the y) Why does this happen? The main essence of my questions are aimed at discovering : a) why the program could be crashing out. b) why the pixel colours on the screen don`t change when the memDC is blit to pDC (the screen device context). Any help would be hugely appreciated as you can imagine. I`ve been working on this for a while, and just can`t figure it out. I`ve checked a lot of articles, but to this day I can`t find one that even attempts to shed light on the situation (except Christians - but the article didn`t really target the issue). If you`ve read this far down, I thank you for that even if you don`t know the answer, Cheers,:confused: :mad: :confused: Alan. P.S. On a slightly different aspect, is there anyway of creating a DIB and intialising its colour to white instead of black? AEGC

    C 1 Reply Last reply
    0
    • C Chambers

      Hi all, I have managed to load/create (as necessary) a 24-bit DIBSection using the means described on this very web site (LR_CREATEDIBSECTION flag in LoadImage and CreateDIBSection), both of which return a HBITMAP. Superb. What I want to do now is "grab" the actual BGR colour values that make up each pixel, and change them to something else such as RGB(0,255,0 - Green, its the easiest example to use). At the moment I am trying to get the bits using a BITMAP structure (returned through GetObject) and its bmBits property. I have also implemented Christians wizardry to convert this pointer to a valid LPBYTE by :

      for (int y=0, y < bm.bmHeight, y++)
      {
      LPBYTE pbSrcRGB = (LPBYTE)&((DWORD*)pDestBits)[y*bm->bmWidth]
      for (int x=0, x < bm.bmWidth, x++)
      {
      pbSrcRGB[0]=0
      pbSrcRGB[1]=255
      pbSrcRGB[2]=0
      pbSrcRGB+=3
      }
      }

      However, the program crashes out after a few laps of the for loops. I have also checked to see whats in pbSrcRGB at position [0] BEFORE assignment and every time it has : 0 '' it is NULL terminated. How is this remedied? BITMAP structure is passed into this function by : &bm and a LPBITMAP structure is then used (as you can see from bm->), so I would have thought that everything was OK from the BITMAP point of view. Also the bitmap starts off black (which I don`t want, thats why I`m changing it all to green), so I assume this is why it reads 0 ''. Also when I check pbSrcRGB[0] to see what it contains AFTER assignment, it reads : 255 'y' (with funny line over the top of the y) Why does this happen? The main essence of my questions are aimed at discovering : a) why the program could be crashing out. b) why the pixel colours on the screen don`t change when the memDC is blit to pDC (the screen device context). Any help would be hugely appreciated as you can imagine. I`ve been working on this for a while, and just can`t figure it out. I`ve checked a lot of articles, but to this day I can`t find one that even attempts to shed light on the situation (except Christians - but the article didn`t really target the issue). If you`ve read this far down, I thank you for that even if you don`t know the answer, Cheers,:confused: :mad: :confused: Alan. P.S. On a slightly different aspect, is there anyway of creating a DIB and intialising its colour to white instead of black? AEGC

      C Offline
      C Offline
      Chris Losinger
      wrote on last edited by
      #2

      try using the <pre>...<pre> tags around code sections. and use < for &"<" characters. about the NULL-terminated and funny-Y characters - don't worry about them. the debugger is displaying the BYTEs as characters.


      http://www.smalleranimals.com

      C 1 Reply Last reply
      0
      • C Chris Losinger

        try using the <pre>...<pre> tags around code sections. and use < for &"<" characters. about the NULL-terminated and funny-Y characters - don't worry about them. the debugger is displaying the BYTEs as characters.


        http://www.smalleranimals.com

        C Offline
        C Offline
        Chambers
        wrote on last edited by
        #3

        Cheers for page authoring advice, it looks much prettier now. So you think everything seems fine, but why does the app crash out? and why do the colours not change? Cheers for the response, Alan. AEGC

        C 1 Reply Last reply
        0
        • C Chambers

          Cheers for page authoring advice, it looks much prettier now. So you think everything seems fine, but why does the app crash out? and why do the colours not change? Cheers for the response, Alan. AEGC

          C Offline
          C Offline
          Chris Losinger
          wrote on last edited by
          #4

          this code might help:

          // find row padding
          int nPad = ds.dsBm.bmWidthBytes - (((ds.dsBmih.biWidth *
          ds.dsBmih.biBitCount) + 7) / 8);

          LPBYTE pbBits = (BYTE*) ds.dsBm.bmBits;
          for (i=0; i<ds.dsBmih.biHeight; i++)
          {
          for (j=0; j<ds.dsBmih.biWidth; j++)
          {
          *(pbBits+0) = 0;
          *(pbBits+1) = 255;
          *(pbBits+2) = 0;
          pbBits+=3;
          }
          pbBits += nPad;
          }


          http://www.smalleranimals.com

          C 1 Reply Last reply
          0
          • C Chris Losinger

            this code might help:

            // find row padding
            int nPad = ds.dsBm.bmWidthBytes - (((ds.dsBmih.biWidth *
            ds.dsBmih.biBitCount) + 7) / 8);

            LPBYTE pbBits = (BYTE*) ds.dsBm.bmBits;
            for (i=0; i<ds.dsBmih.biHeight; i++)
            {
            for (j=0; j<ds.dsBmih.biWidth; j++)
            {
            *(pbBits+0) = 0;
            *(pbBits+1) = 255;
            *(pbBits+2) = 0;
            pbBits+=3;
            }
            pbBits += nPad;
            }


            http://www.smalleranimals.com

            C Offline
            C Offline
            Chambers
            wrote on last edited by
            #5

            Well, you truly are a magician of the C++ variety, the code example you gave me worked superbly. However, there is one slight problem which is preventing me from tarring you with the same golden brush as Gandalf the Great. The bitmap goes green alright, but for only a second, and then where I draw some lines in some code after it, it flicks back to bl**dy black. Please enlighten me. Also, I just like to thank you for that piece of code you gave me, for the page authoring tips you mentioned, and, well...for bothering to reply at all. Cheers mate, I owe you one, Alan.:)

            C 1 Reply Last reply
            0
            • C Chambers

              Well, you truly are a magician of the C++ variety, the code example you gave me worked superbly. However, there is one slight problem which is preventing me from tarring you with the same golden brush as Gandalf the Great. The bitmap goes green alright, but for only a second, and then where I draw some lines in some code after it, it flicks back to bl**dy black. Please enlighten me. Also, I just like to thank you for that piece of code you gave me, for the page authoring tips you mentioned, and, well...for bothering to reply at all. Cheers mate, I owe you one, Alan.:)

              C Offline
              C Offline
              Chris Losinger
              wrote on last edited by
              #6

              :) hmmm... not sure about this one. are you re-drawing the bitmap anywhere? -c


              http://www.smalleranimals.com

              C 1 Reply Last reply
              0
              • C Chris Losinger

                :) hmmm... not sure about this one. are you re-drawing the bitmap anywhere? -c


                http://www.smalleranimals.com

                C Offline
                C Offline
                Chambers
                wrote on last edited by
                #7

                I have finally found what was going wrong! I had selected the wrong hbitmap into the DIBSECTION (it was the background layer), thats why it was flicking up so quickly, it was being replaced by the new black background I just created. Just thought I`d post the solution in case anybody else has a similar problem. My thanks go Chris on majorly helping me through the subject. I`ll also thank Christian for his part on getting me on the right road to success. Cheers guys, Alan.:)

                1 Reply Last reply
                0
                Reply
                • Reply as topic
                Log in to reply
                • Oldest to Newest
                • Newest to Oldest
                • Most Votes


                • Login

                • Don't have an account? Register

                • Login or register to search.
                • First post
                  Last post
                0
                • Categories
                • Recent
                • Tags
                • Popular
                • World
                • Users
                • Groups