> This seems to work - Is this more or less what you had in mind ? I had > also experimented with a loBmp.GetPixel approach but did not get very > far - and in any event the research I have done would seem to suggest > that the approach here is probably faster than an approach using > GetPixel would you agree ?
loBmp.GetPixel is really veeeeeeeeeeeeeeeeeeeeeeeeeeeeeery sloooooooooooooooooooooooow, comparing to the way you did using Lockbits() The way you did is the best I can think of. But if you really need a good performance, the memory management using C++ is really recommended, and I ensure you that you can do the same task about more than 100 times faster. HTH Cesar ----- Original Message ----- From: "Paul Newton" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, July 22, 2007 7:38 PM Subject: Re: Finding/Enumerating colors used in an image > Thanks for the reply, Malcolm > > This is what I have come up with (before seeing your reply) and I think > it might be along the lines of what you are suggesting. I have tried to > pare the code to a minimum here, so don't worry about lack of > declarations or assumptions about what has gone before: > > WITH _SCREEN.System.Drawing > > loBmp = .Bitmap.New(GETFILE()) > loRect = .Rectangle.New(0, 0, loBmp.Width, loBmp.Height) > loBmpData = loBmp.LockBits(loRect, .Imaging.ImageLockMode.ReadOnly, ; > _screen.System.Drawing.Imaging.PixelFormat.Format24bppRGB) > > FOR y = 0 TO loBmpData.Height - 1 > FOR x = 0 TO loBmpData.Width - 1 > > lnPos0 = loBmpData.Scan0 + (loBmpData.Stride * y) + (3 * x) > > b = ASC(SYS(2600, lnPos0, 1)) > g = ASC(SYS(2600, lnPos0 + 1, 1)) > r = ASC(SYS(2600, lnPos0 + 2, 1)) > lnRGB = RGB(r,g,b) > > IF ASCAN(aColors,lnRGB,1,lnColors) = 0 > lnColors = lnColors+1 > DIMENSION aColors(lnColors) > aColors(lnColors) = lnRGB > ENDIF > > NEXT > NEXT > > MESSAGEBOX(TRANSFORM(lnColors) + " colors found") > > ENDWITH > > This seems to work - Is this more or less what you had in mind ? I had > also experimented with a loBmp.GetPixel approach but did not get very > far - and in any event the research I have done would seem to suggest > that the approach here is probably faster than an approach using > GetPixel would you agree ? > > Any further comments/suggestions ? > > Paul > > > Malcolm Greene wrote: >> Paul, >> >> Try using the GDIPlusX library to load the image into memory, then save >> the image to disk as a 24 bit BMP. >> >> The 24 bit BMP file format stores each pixel as a 3 byte (24 bit) RGB >> value. If I remember correctly, the actual RBG values will be stored >> in BGR order (vs. RGB order) if you're parsing a BMP file char by >> char. >> >> To parse the BMP file, you have to read past the BMP header and then >> read pixels by rows. I believe that each row must start on an boundary >> that is divisible by 4 so you need to account for some empty padding at >> the end of each row. >> >> I believe that Christof has written some FoxPro Advisor articles about >> how to do this. I also believe there may be some sample code on how to >> do this in the Profox archives from Christof and Cesaer. >> > > > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
