NO

Author Topic: image processing  (Read 9326 times)

defunktlemon

  • Guest
image processing
« on: December 19, 2012, 01:06:50 AM »
Hi can anyone help me read in and display two images using C language. I have a school project which needs to compare two images and difference / subtract and display difference in new image. It requires the following steps basically:
I think I would like to develop this bit by bit. So, I guess I need to look at all the processes I need to complete and tackle them one by one in separate functions. So first,
1. I need to load the .jpeg images into C and probably turn them into binary / black & white. This will reduce the file size which is good.
2. I need to align the images
3. I need to difference the images and show the new image
4. I need to locate the center of the difference object and create a bounding box around them
5. The objects once located need to be detailed
So, for 1, will I need to import all the image pixel values into an array / matrix?

Thank you
P.S. I'm really not a good programmer and this is going to be a big learning curve to take slowly over the next 3 weeks.

CommonTater

  • Guest
Re: image processing
« Reply #1 on: December 19, 2012, 02:49:51 AM »
This is a homework assignment, so you're pretty much on your own...
I doubt you'll find anyone here who's going to do your homework for you.

That said, if you get stuck on something specific, you're welcome to post the misbehaving code and ask specific questions about it...


migf1

  • Guest
Re: image processing
« Reply #2 on: December 19, 2012, 01:51:48 PM »
...
So, for 1, will I need to import all the image pixel values into an array / matrix?

Thank you
P.S. I'm really not a good programmer and this is going to be a big learning curve to take slowly over the next 3 weeks.

Hello,

I'm not really into image processing, but the above question seems to have an obvious (positive) answer. Unless of course you later need to do some more advanced stuff, in which case a raw array of "pixels" wouldn't be really helpful.

For example, you will probably need to know each pixel's position (either absolute or as an offset) its current color (usually expressed as RGB bytes), and stuff like that.

I don't know what's the industry standard for storing pixels, but representing a pixel entity as a struct, say...

Code: [Select]
typedef struct Pixel {...}Pixel;
consisting of all the fields needed for any individual pixel, and then use a buffer for storing all your image's pixels...

Code: [Select]
Pixel *image = malloc( npixels * sizeof(Pixel) );
...
// do what you have to do here
...
if ( image )
    free( image );  // free memory reserved for your image, before program termination
exit( EXIT_SUCCESS);

seems to me like a promising idea.

To obtain the required number of pixels, decompression directives, color formatting, etc you should read your image file's header, which differs among different image formats. I suppose your teacher have explicitly explained the format of the images he wants you to manipulate.
« Last Edit: December 19, 2012, 01:59:05 PM by migf1 »

CommonTater

  • Guest
Re: image processing
« Reply #3 on: December 19, 2012, 03:11:14 PM »
Hi Mig...
It's a bit more complex than that... .jpg images are compressed (lzw?) and his first problem will be to decompress the file into memory.  That will give him a bitmap in memory onto which he can overlay structure such as width, height, pixel mapping etc...

So before he can do anything else he needs to get the images into memory, in identical formats.

The matter of showing file difference is pretty easy... bytewise xor one image against the other... whatever is left is the difference between them.


migf1

  • Guest
Re: image processing
« Reply #4 on: December 19, 2012, 03:28:55 PM »
Sorry if it was not clear in my previous post, the custom Pixel type I suggested was referring to already uncompressed data.

As I said, I'm not into image-processing, but it seems like a natural way to implement. Otherwise, how would we know what's the position of a pixel, for example?
 
« Last Edit: December 19, 2012, 03:30:30 PM by migf1 »

CommonTater

  • Guest
Re: image processing
« Reply #5 on: December 19, 2012, 03:31:54 PM »
For the position of pixels ... so long as the source images are exactly the same size file order will suffice.  It's when the images are different sizes or shapes that the fun begins... You have to somehow align the images before passing over them with your math....
 
But... those are fine details that are part of the OP's homework assignment.
So, I'm suggesting that he's best left to work that out for himself...
LOL... unless we want him to be graded on our work....
 
(Make no mistake... he IS asking us to do his homework...)
 
« Last Edit: December 19, 2012, 03:34:48 PM by CommonTater »

migf1

  • Guest
Re: image processing
« Reply #6 on: December 19, 2012, 03:37:16 PM »
LOL

But anyway, I'm just curious. Is all this individual pixel info packed let say in a byte or two (or more)? In that case, we wouldn't need separate struct fields for them, since we could simply access them directly from their corresponding bytes (or bits).


CommonTater

  • Guest
Re: image processing
« Reply #7 on: December 19, 2012, 03:42:31 PM »
It depends on the image format (and here I'm no expert)... Paletized images can sometimes store the entire colour information in a single byte (e.g. 256 color icons), some more advanced images use words to signify 5 bits each for Red Green and Blue (e.g. 16bit bmp) Then there are the 24 bit images that use one byte each for Red Green and Blue.  (This was the default Windows colour space for a long time).  Now we have 32 bit images with one byte each for Red Green and Blue with a fourth byte added for transparency effects (as in the Windows Aero colour space and most jpg and png images)

So... our friend might have to use bytes, words, 3 byte structs or dwords to access his colour information, depending on the image he's handed and that information will likely come from the file header itself.
 
Feel free to correct me if I'm wrong on this... (doing it from memory)

 
« Last Edit: December 19, 2012, 04:10:53 PM by CommonTater »

migf1

  • Guest
Re: image processing
« Reply #8 on: December 19, 2012, 03:52:15 PM »
That's cool, thanks for satisfying my curiosity :)


CommonTater

  • Guest
Re: image processing
« Reply #9 on: December 19, 2012, 04:18:48 PM »
That's cool, thanks for satisfying my curiosity :)

No worries... (Lets hope I got it right, I haven't done this in quite a while).

Offline jj2007

  • Member
  • *
  • Posts: 536
Re: image processing
« Reply #10 on: December 19, 2012, 08:20:28 PM »
Hi defunktlemon,

For a start, read the docu of
GdipLoadImageFromFile
GdipGetImageWidth and GdipGetImageHeight
GdipCreateFromHDC
GetDIBits
Manipulation of the matrix should be straightforward, and GetDIBits should do the rest.

Offline Stefan Pendl

  • Global Moderator
  • Member
  • *****
  • Posts: 582
    • Homepage
Re: image processing
« Reply #11 on: December 19, 2012, 10:04:42 PM »
No worries... (Lets hope I got it right, I haven't done this in quite a while).

The basics are still as you describe and valid for GDI, but GDI+ allows quite some more things.

In the end if you read any image format into memory using GDI API functions your result will be a BMP-like structure.

The questions are:
1) Must this be cross-platform code or only Windows?
2) Is using GDI/GDI+ allowed or not?
3) Must we work on the raw file format or not?

Without the whole assignment, we won't be able to give the OP a nudge into the right direction.
---
Stefan

Proud member of the UltraDefrag Development Team

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 2096
Re: image processing
« Reply #12 on: December 20, 2012, 09:51:32 AM »
Hmmm....
I think that the scope of the assignement is 'the' image processing, but our friend has underconsidered the complexity of code from a raw image to a matrix to work on...  ::)
If I'm right I suggest you to start with two images already in matrix format in two separate files (the conversion made with wathever system or tool you can find) and start to develop core algorithms on that.
Then you can explain that the low level image handling is not as simple as could seem, and that it will be handled in future to not delay core development or so...... 8)
Than you can clarify how to handle the issue, choose what to use: GDI, JPEG library or whatever could fit the project.
« Last Edit: December 20, 2012, 09:53:08 AM by frankie »
It is better to be hated for what you are than to be loved for what you are not. - Andre Gide

defunktlemon

  • Guest
Re: image processing
« Reply #13 on: January 24, 2013, 06:18:23 PM »

(Make no mistake... he IS asking us to do his homework...)

CommonTater, I'm not sure why you would make such a comment. What part of my original post of this thread gave you the impression that I didn't want to learn during the process of achieving my project goals? Kindly take more care in you comments, less you wish to continue to offend and brand people unfairly.