count colors in bitmap
in [Visual Basic]
|
From: Mike Williams on 14 Jul 2010 06:19 "Ulrich Korndoerfer" <ulrich_wants_nospam(a)prosource.de> wrote in message news:i1j8v7$kkn$1(a)online.de... > My three versions use different access methods. > gUniqueColorCountFromDIB1 has less complicated > code and is a bit slower than yours. > gUniqueColorCountFromDIBByte has easy code and > is nearly as fast as gUniqueColorCountFromDIB. > gUniqueColorCountFromDIB has complicated code > and is as fast as your version That's fine. Ulrich. I wasn't actually making a big thing about the speed issue between my own code and yours. In fact it was Charles who mentioned the speed when he said. ["Thanks Ulrich. That's almost as fast as Mike's code so it should be quite useful but there is one little problem with your code in that it crashes on some bitmaps and I get the "Send Error Report to Microsoft" message box"]. As far as I am concerned, both your own code and mine are very fast for the job they are doing. By the way, from the tone of your message I get the idea that you are turning this into some kind of aggressive contest? Perhaps it might be better, and perhaps we both might actually learn something from it, if we instead discussed this thing rationally and if neither of us let our egos get in the way ;-) What do you think? > For the sizes you mentioned the code does access a byte that lies > outside the memory occupied by the DIB data, but does not crash. > I did some rework of my code. It does not crash on those sizes. > I have setup a test project, available under > <http://www.prosource.de/Temp/CountUniqueColors.zip> I'm not sure whether you are saying that the code you originally posted does not crash on certain specific image sizes (which in fact it very definitely does on my two machines), or whether you are saying that a new modified version of that code which you produced after reading my comments does not crash? I can guarantee that the code you originally posted very definitely does crash on certain specific image sizes on my two machines, and it very likely does so for the reasons I mentioned earlier. In fact I've just tried your original posted code again on both my machines (one Vista, one XP) using a 3200 x 2400 pixel test images and it bombs out every time, crashing when run as a compiled exe and crashing the VB IDE if it is run in the IDE. What I'll do is download your new project at the link you have have just given and I'll give your new versions a whirl . . . .. . . Okay. I've tried your new project which produces timing results for the specific small test image you are using, both for my own code and for three different versions of your code. I ran it first exactly as it stands (in which it uses your own small "testpic.bmp" 131 x 107 pixel image) and, as expected, it ran fine, producing a timing result for all four methods (my own being tested first, followed by your own three methods). I then dragged your own testpic.bmp image out of your TestPics folder and replaced it with a testpic.bmp of my own, a 3200 x 2400 pixel bitmap. I did not touch your code at all. I then ran your code again. This time it crashed, bombing out just after it had successfully run and reported the results of my own code. So, in your own test project my own code worked fine on that image, but yours did not, causing a crash. Further testing showed that both the first two of your own three methods (UniqueColorCountFromDIB and gUniqueColorCountFromDIB1) caused a crash and only your third method (gUniqueColorCountFromDIBByte) worked. I would post a screen grab of your crashed program and the system error message box, but I don't think aioe.org would accept it, and perhaps your newsreader might be set not to download it anyway. > gUniqueColorCountFromDIB andgUniqueColorCountFromDIB1 > both can treat the last pixel problem. There is a compilation constant > (LASTPIXELSPECIALTREATMENT) in MFinal, which switches > special treatment of the last pixel on or off. When off, for the sizes > you mentioned above, the code does access a byte that lies outside > the memory occupied by the DIB data, but does not crash. Well that's not what I'm getting at this end, Ulrich. When I download your new test project from the link you posted and when I run it exactly as it stands, but using a 3200 x 2400 pixel testpic.bmp image instead of your own small test bitmap, it bombs out immediately after it has successfully reported the results from my own version, crashing as soon as it attempts to run your version. It does work okay if I set the LASTPIXELSPECIALTREATMENT flag that you incorporated after reading my previous postings, but it bombs out if I run your new code as it stands, and your original posted code also bombs out on that image. I haven't yet tested whether your new code also bombs out on the other various image sizes I mentioned (I'll do that later) but it very definitely bombs out on the 3200 x 2400 image. Did you actually try it yourself? If so, and if it was successful on that image size, then perhaps there is something different about the way your own machine is allocating the DIB memory? Perhaps others here might like to download your code from the link you posted and run it after replacing the small testpic.bmp image in your TestPics folder with a 3200 x 2400 pixel testpic.bmp of their own? It might be interesting to see whether it bombs out on other machines as well as on my own two machines, and also which machines it bombs out on and which machines it does not? It could be interesting to check out this 4KB etc chunk thing further. I'm sure you won't mind me reposting your link here: http://www.prosource.de/Temp/CountUniqueColors.zip > BTW, your code counts wrong on bitmaps having > a width of either 1, 2 or 3 pixels. Thanks for that, Ulrich. I had not considered images of such a size. I can see now that my code as it stands would not work properly on such an image, because it assumes that there will actually be at least one block of four pixels on a scanline. Thanks for pointing that out. I'll get it sorted. > And, when run in the IDE, would most probably crash > on a system with more than 2 GB process memory. Thanks again Ulrich. I'll get onto that one as well. Presumably you mean that it will fall down where I am adding a small value (3, 6 or 9) to a memory pointer if that pointer initially happens to be very close to the maximum signed positive value? I haven't looked at your point in detail yet, but my initial thoughts are that it is likely to be a very remote possibility (because I think that all other lesser initial positive pointer values and all pointer values which were already "seen as negative" by VB would be fine, and the system is not going to allocate a DIBSection on such an odd starting point). However, I must admit that I never even considered that possibility. My own systems allocate 2GB max per process and I thought that was pretty much the norm. Thanks for pointing it out. I also thought that perhaps VB6 would not work properly anyway where it is allocated more than 2GB for the process. Does it work okay on such machines? I do actually take precautions to deal with the 2GB (and also the 4GB) problem when I am dealing with other things, disk file sizes and other things, but I never even considered doing it when dealing with normal data pointers in VB6, although now that your remarks have prompted me to think about it I suppose I should really take it into account when dealing with a DIB data address obtained from a GDI function. Thanks again Ulrich for pointing that out. Mike
From: senn on 14 Jul 2010 10:06 "Ulrich Korndoerfer" <ulrich_wants_nospam(a)prosource.de> skrev i meddelelsen news:i1j9mq$me3$1(a)online.de... > Hi, > > sorry for replying so late. > > charles schrieb: > >> ... >> Thanks Ulrich. That's almost as fast as Mike's code so it should be >> quite useful. There is one little problem with your code though in >> that it crashes on some bitmaps and I get the "Send Error Report to >> Microsoft" message box. Any idea what might be causing that? >> ... > > No. I reworked my code a little bit. You can download a test project from > > <http://www.prosource.de/Temp/CountUniqueColors.zip> > Ulrich, The OP's problem became solved with Mikes posting of his solution to the problem. You noticed his posting before posting your second, according to quite a difference between the two postings. Why show up again in such a case!. Honestly, why not just post a "I stand corrected" or alike. I also have difficult to read, whether you tell the readers, that you corrected your code for an error, that were pointed out by Mike, or trying to - what /se
From: Ulrich Korndoerfer on 15 Jul 2010 20:31 Hi, senn schrieb: > > "Ulrich Korndoerfer" <ulrich_wants_nospam(a)prosource.de> skrev i > meddelelsen news:i1j9mq$me3$1(a)online.de... >> Hi, >> >> sorry for replying so late. >> >> charles schrieb: >> >>> ... >>> Thanks Ulrich. That's almost as fast as Mike's code so it should be >>> quite useful. There is one little problem with your code though in >>> that it crashes on some bitmaps and I get the "Send Error Report to >>> Microsoft" message box. Any idea what might be causing that? >>> ... >> >> No. I reworked my code a little bit. You can download a test project from >> >> <http://www.prosource.de/Temp/CountUniqueColors.zip> >> > > Ulrich, > The OP's problem became solved with Mikes posting of his > solution to the problem. No, it isn't. Mikes routine has some flaws. You noticed his posting before posting > your second, according to quite a difference between the two postings. I don't need others code to write my own. Perhaps (I doubt) you have recognized, that my first post to the OP was labeled "top off my head" in my second post to the OP. For you to clarify: my first post was a 5 minute thing, written direct into the post (not using the IDE), and gave the OP a way how to handle such a problem. It obviously depended on the colors being already in RGBA format in a Long array, which easily can be deduced from my code. Then Mike came up with that DIB thing, using LoadImage. Ok, I did not wite in my first post how to obtain the colors. So I decided to go this route for *loading* the pixel data. However in this case pixels are not in RGBA format and are organized in scanlines (with padding), and I had to write new code, that counts colors being in such format. That was my second post to the OP. > Why show up again in such a case!. > Honestly, why not just post a "I stand corrected" or alike. Why should I? There is nothing to correct until now. > I also have difficult to read, whether you tell the readers, that > you corrected your code for an error, that were pointed out > by Mike, or trying to - what Sigh. You seemingly do not understand the code I made available in my third post to the OP (by link). If you would have read the code from my third post and would have understood it, you would not ask such a silly question. Ok, as a courtesy to a slower guy: charles posted, that my code (second version) sometimes crashes. Mike posted, that this might be because my second version, when accessing the last pixel, always accesses one byte more than necessary (it uses a Long array for accessing the 3 pixel bytes). And that this with certain bitmaps (those with no scanline padding and using a multiple of 4 kiB for the DIB pixel data) will crash. Now I of course had tested this before posting the second version. I had no crashes (eg on a 1024 x768 butmap, with fulfills the mentioned conditions). So my honest answer to charles was, that I do not know why he has crashes. *And* I posted a new, third version, which now can be switched (using a compile time constant), between code that accesses the pixels in the same way as my second version does and a modified version that does special processing for the last pixel, not accessing more than the necessary 3 bytes for the last pixel. This is not an error correction. Until now I do not have crashes on bitmaps with my second version and the third version without last pixel special treatment. The search why my code crashes still is unclear. This is the reason, why I made my third version. As said, accessing the last pixel without special treatment does not crash on my machine, especially not for those peculiar kinds of bitmaps mentioned above. So there must be some other reason. To verify this, I wrote the third version. Now the OP (as I asked for), can run my code on those bitmaps he had crashes with. For those bitmaps I asked him to run both kinds: with and without special treatment. If in both cases he has crashes, this would prove that there must be another reason. If only the kind without special treatment crashes, there still is the question, why then those kind of bitmaps do not crash on my machine. Then the next step would be, to send me such bitmap, and I will try it on my machine. And of course I reworked in the third version the second version. One reason was, that additionally I offer two further functions. Because all three share some code, which could be without loosing speed refactored into their own method, I did that. Then I had to change the pointer setting up and tearing down routines to now work with either long or byte arrays. And I changed the UAdd routine, which now is a tad smaller and faster. And I changed the Flags and Bitmasks array from dynamic to static (tad faster). And special to gUniqueColorCountFromDIB I precalculate now the innermost topindex outside and also do the scanline pointer correction for each scanline now by addition, not by multiplication with the scan line index (again a tad faster). But all those changes do not alter how gUniqueColorCountFromDIB accesses the last pixel, when LASTPIXELSPECIALTREATMENT is set to 0. If (as said, not on my machine), the second version crashes on eg 1024x768 bitmaps, the third version would crash too. You could have seen that, if you had read and if you had understood the code. -- Ulrich Korndoerfer VB tips, helpers, solutions -> http://www.prosource.de/Downloads/ MS Newsgruppen Alternativen -> http://www.prosource.de/ms-ng-umzug.html
From: Ulrich Korndoerfer on 15 Jul 2010 20:42 Hi, Mike Williams schrieb: > > Well that's not what I'm getting at this end, Ulrich. When I download > your new test project from the link you posted and when I run it exactly > as it stands, but using a 3200 x 2400 pixel testpic.bmp image instead of > your own small test bitmap, it bombs out immediately after it has > successfully reported the results from my own version, crashing as soon > as it attempts to run your version. It does work okay if I set the > LASTPIXELSPECIALTREATMENT flag that you incorporated after reading my > previous postings, but it bombs out if I run your new code as it stands, > and your original posted code also bombs out on that image. I haven't > yet tested whether your new code also bombs out on the other various > image sizes I mentioned (I'll do that later) but it very definitely > bombs out on the 3200 x 2400 image. Did you actually try it yourself? If > so, and if it was successful on that image size, then perhaps there is > something different about the way your own machine is allocating the DIB > memory? > I did not test on a 3200x2400 bitmap. That should not be necessary, because a 1024x768 bitmap fulfills the same condition: no scanline padding (which you forget to mention) and memorysize for the pixel data being a multiple of 4 kiB. So if your suspection, that this causes a crash when accessing the last pixel without taking special mesures ,it should crash on 1024x768 bitmaps too. But it did not crash on my machine, wether using my second version or my third version with or without special treatment for the last pixel. To say it again: my third version, when LASTPIXELSPECIALTREATMENT is set to 0 (as is the set case in the downloadable project), and such does not treat acccess to the last pixel in a special way, is *functionally* identical to my second version, so either both crash or not. You cluld have seen that from reading the code. -- Ulrich Korndoerfer VB tips, helpers, solutions -> http://www.prosource.de/Downloads/ MS Newsgruppen Alternativen -> http://www.prosource.de/ms-ng-umzug.html
From: senn on 16 Jul 2010 02:35
"Ulrich Korndoerfer" <ulrich_wants_nospam(a)prosource.de> skrev i meddelelsen news:i1o99v$e6l$1(a)online.de... > Hi, > > senn schrieb: >> >> "Ulrich Korndoerfer" <ulrich_wants_nospam(a)prosource.de> skrev i >> meddelelsen news:i1j9mq$me3$1(a)online.de... >>> Hi, >>> >>> sorry for replying so late. >>> >>> charles schrieb: >>> >>>> ... >>>> Thanks Ulrich. That's almost as fast as Mike's code so it should be >>>> quite useful. There is one little problem with your code though in >>>> that it crashes on some bitmaps and I get the "Send Error Report to >>>> Microsoft" message box. Any idea what might be causing that? >>>> ... >>> >>> No. I reworked my code a little bit. You can download a test project >>> from >>> >>> <http://www.prosource.de/Temp/CountUniqueColors.zip> >>> >> >> Ulrich, >> The OP's problem became solved with Mikes posting of his >> solution to the problem. > > No, it isn't. Mikes routine has some flaws. > > You noticed his posting before posting >> your second, according to quite a difference between the two postings. > > I don't need others code to write my own. Perhaps (I doubt) you have > recognized, that my first post to the OP was labeled "top off my head" in > my second post to the OP. > > For you to clarify: my first post was a 5 minute thing, written direct > into the post (not using the IDE), and gave the OP a way how to handle > such a problem. It obviously depended on the colors being already in RGBA > format in a Long array, which easily can be deduced from my code. > > Then Mike came up with that DIB thing, using LoadImage. Ok, I did not wite > in my first post how to obtain the colors. So I decided to go this route > for *loading* the pixel data. However in this case pixels are not in RGBA > format and are organized in scanlines (with padding), and I had to write > new code, that counts colors being in such format. That was my second post > to the OP. > >> Why show up again in such a case!. >> Honestly, why not just post a "I stand corrected" or alike. > > Why should I? There is nothing to correct until now. > >> I also have difficult to read, whether you tell the readers, that >> you corrected your code for an error, that were pointed out >> by Mike, or trying to - what > > Sigh. You seemingly do not understand the code I made available in my > third post to the OP (by link). If you would have read the code from my > third post and would have understood it, you would not ask such a silly > question. > > Ok, as a courtesy to a slower guy: > > charles posted, that my code (second version) sometimes crashes. Mike > posted, that this might be because my second version, when accessing the > last pixel, always accesses one byte more than necessary (it uses a Long > array for accessing the 3 pixel bytes). And that this with certain bitmaps > (those with no scanline padding and using a multiple of 4 kiB for the DIB > pixel data) will crash. > > Now I of course had tested this before posting the second version. I had > no crashes (eg on a 1024 x768 butmap, with fulfills the mentioned > conditions). > > So my honest answer to charles was, that I do not know why he has crashes. > > *And* I posted a new, third version, which now can be switched (using a > compile time constant), between code that accesses the pixels in the same > way as my second version does and a modified version that does special > processing for the last pixel, not accessing more than the necessary 3 > bytes for the last pixel. > > This is not an error correction. Until now I do not have crashes on > bitmaps with my second version and the third version without last pixel > special treatment. The search why my code crashes still is unclear. This > is the reason, why I made my third version. > > As said, accessing the last pixel without special treatment does not crash > on my machine, especially not for those peculiar kinds of bitmaps > mentioned above. So there must be some other reason. To verify this, I > wrote the third version. Now the OP (as I asked for), can run my code on > those bitmaps he had crashes with. For those bitmaps I asked him to run > both kinds: with and without special treatment. If in both cases he has > crashes, this would prove that there must be another reason. If only the > kind without special treatment crashes, there still is the question, why > then those kind of bitmaps do not crash on my machine. Then the next step > would be, to send me such bitmap, and I will try it on my machine. > > And of course I reworked in the third version the second version. One > reason was, that additionally I offer two further functions. Because all > three share some code, which could be without loosing speed refactored > into their own method, I did that. Then I had to change the pointer > setting up and tearing down routines to now work with either long or byte > arrays. And I changed the UAdd routine, which now is a tad smaller and > faster. And I changed the Flags and Bitmasks array from dynamic to static > (tad faster). And special to gUniqueColorCountFromDIB I precalculate now > the innermost topindex outside and also do the scanline pointer correction > for each scanline now by addition, not by multiplication with the scan > line index (again a tad faster). > > But all those changes do not alter how gUniqueColorCountFromDIB accesses > the last pixel, when LASTPIXELSPECIALTREATMENT is set to 0. If (as said, > not on my machine), the second version crashes on eg 1024x768 bitmaps, the > third version would crash too. You could have seen that, > if you had read and if you had understood the code. > Where's the logic ! Do you expect me to understand code without reading it !. Your long explanation above can't convince me: On the Contrary to, it just proved what I expected and researched for "Your wantings alignes to show off". > Ok, as a courtesy to a slower guy You would like to preserve your imagination of being a faster guy. That's apparently a basement for your personallity. It's manageable reading up on bitmaps http://msdn.microsoft.com/library/en-us/gdi/ Even a slow guy -like you - can do it !. /se > -- > Ulrich Korndoerfer > > VB tips, helpers, solutions -> http://www.prosource.de/Downloads/ > MS Newsgruppen Alternativen -> http://www.prosource.de/ms-ng-umzug.html |