Extract largest continuous pixel section

[el_supremo]

I can think of one way to speed it up but you'll have to implement it yourself.
The program goes along each row looking for black pixels. When it finds one, the addq macro tests every coordinate to make sure that it falls within the image. If the program is rewritten so that it does a separate check for the edges of the image, testing of all the interior pixels can omit the test which ensures that the surrounding pixels are within the image.
To do this, the program could first use four loops, one to check the top row, one for each side and one for the bottom row, with each of these loops using the existing addq macro.
Then you can change the existing loop from:

Code: Select all

   for(j=0;j<height;j++) {
      for(i=0;i<width;i++,p++) {

to:

Code: Select all

   for(j=1;j<height-1;j++) {
      for(i=1;i<width-1;i++,p++) {

and then within this loop use a different macro, say "addiq", which is the same as addq except that it doesn't have the first "if" statement because we know that any black pixel we find now can't be on the edge of the image and therefore we don't have to check for edge effects.

I have no idea how much this would speed up the code, if at all, but it's worth a try.

Pete

[anthony]

But still the program is slow, taking approx 10 sec which is enormous if we have thousands of pics.

el_supremo's method of 'flood filling' using a stack of 'neighbors' is not one of the most efficient methods, that can be used, but I see he has addressed the issue.

I should know as back in my Commodore 64 day (yes I am that old!) I explored many styles of flood filling. At that time computers were slow enough that if you displayed the flood fill you could watch it do the job!

Then again my script would be even slower due to IO requirements, and the fact that the script has to start looking for new segments from the beginning again (and not from where it removed the last segment).

On the other hand my script is a general segmentation, and not a specific one.

[imagetester]

huge Problem !!!!!

You started by an 8 bit image, you added red so what is the resulting image depth ?! (blob.gif?!)

I need to work a bit on the resulting image so i have outputted blob.bmp instead of blob.gif so i can read it with basic c/c++;

But i was surprised to get the image depth at 196640 bits/pixel !!!!!!
Please don't tell me that my code is wrong i'm 100% sure of it:

Code: Select all

long getImageInfo(FILE* inputFile, long offset, int numberOfChars)
{
  unsigned char			*ptrC;
  long				value=0L;
  int				i;
  unsigned char			dummy;


  dummy = '0';
  ptrC = &dummy;

  fseek(inputFile, offset, SEEK_SET);

  for(i=1; i<=numberOfChars; i++)
  {
    fread(ptrC, sizeof(char), 1, inputFile);
    /* calculate value based on adding bytes */
    value = (long)(value + (*ptrC)*(pow(256.0, (i-1)*1.0)));
  }

  return(value);
}

printf("Bits/pixel: %d\n", getImageInfo(bmpInput, 28, 4));

I need to convert the image depth to 24 bits/pixel.
I tried MagickSetImageDepth(m_wand,24) but it was not doing its job.

so I tried MagickQuantizeImage(m_wand,0,RGBColorspace,0,MagickBooleanType::MagickFalse,MagickBooleanType::MagickFalse);

again nothing happens same result.


NB: I've added these functions everywhere not in a specific location

Any ideas ?!
Thanks

[el_supremo]

Please don't tell me that my code is wrong i'm 100% sure of it:

It's wrong.

The biBitField member of the BITMAPINFOHEADER is indeed offset 28 bytes from the beginning of standard BMP file but it is not a 32-bit integer - it is 16 bits.
If you convert your result of 196640 to hex, you get 00030020. Since you stored the bytes in to "value" starting at the low order end of the word, what you have there is a biBitCount of hex0020 = 16 (bits per pixel) and biCompression = 3.

Pete

[imagetester]

Please don't tell me that my code is wrong i'm 100% sure of it:

It's wrong.

The biBitField member of the BITMAPINFOHEADER is indeed offset 28 bytes from the beginning of standard BMP file but it is not a 32-bit integer - it is 16 bits.
If you convert your result of 196640 to hex, you get 00030020. Since you stored the bytes in to "value" starting at the low order end of the word, what you have there is a biBitCount of hex0020 = 16 (bits per pixel) and biCompression = 3.

Pete

How can I remove the compression?!
I need to have an image with 24 bits depth and uncompressed !!
I mean the 28 byte offset should be a 32-bit integer as a standard image!!!!

Thanks

[el_supremo]

what you have there is a biBitCount of hex0020 = 16 (bits per pixel) and biCompression = 3.

Where was my brain when I wrote that?? hex 0020 is 32 (NOT 16). I think it implies that there's an alpha layer as well as the RGB layers. I'll check up on that.



Pete

[el_supremo]

I think it (32) implies that there's an alpha layer

Apparently, not. It means there are at most 2^32 colours.

Why are you reading the header anyway? Use ImageMagick to read the BMP file for you.

Pete

[imagetester]

I think it (32) implies that there's an alpha layer

Apparently, not. It means there are at most 2^32 colours.

Why are you reading the header anyway? Use ImageMagick to read the BMP file for you.

Pete

I'm working on an image processing project, and all the images need to be formatted to 24 bits/pixel ( B,G,R with no alpha layer and no compression)
Well I've tried to include Magick++ to this project but it has generated many errors!! Apparently you can not include the wand and the magick++ together. Which is why i've decided to read the bmp image in the low level using basic C/C++ functions.

If converting to 24 bit/pix is impossible I have a small request for you:
In fact I need to add a small extension to your code:

After that the largest continuous pixel section is highlighted in red I need to extract it ( crop image ) and convert it back to black (8bit/pixel or 24), in addition the program outputs another image without this largest continuous pixel section ( also i prefer an 8-bit or 24-bit WITH no compression)

In the given example the program outputs the number "9" (in black) and the remain of the images without the image (also in black)

I could do it myself but i'm not able to use magick++ neither the low-level C/C++, and i don't really like the wand programming.
Thanks,

[el_supremo]

Well I've tried to include Magick++ to this project but it has generated many errors!! Apparently you can not include the wand and the magick++ together.

I don't use C++, but my understanding is that Magick++ is a C++ wrapper for MagickWand. So, I presume that you would have to convert my code to C++/Magick++.

After that the largest continuous pixel section is highlighted in red I need to extract it ( crop image ) and convert it back to black (8bit/pixel or 24), in addition the program outputs another image without this largest continuous pixel section ( also i prefer an 8-bit or 24-bit WITH no compression)

You can do this with the convert command. Using your 48879665cd8.png file as an example, use my program to produce the blob.gif file, then:

Code: Select all

convert blob.gif -fill white -opaque black -fill black -opaque red black_blob.gif
convert 48879665cd8.png black_blob.gif -compose difference -composite -negate blob_diff.gif

The output of the first command is an image with just the black "9". The second command produces an image with the "9" removed. There are probably better ways to do this (there's probably a composite operator which won't need the -negate) and I presume that it can all be done in one command.


Pete

[anthony]

A new topic continuing this discussion is in...
http://imagemagick.org/discourse-server ... =1&t=18283

Any new comments or replays should be made there. -- This Discussion is now Locked.