writing wrong bytes

This is a discussion on writing wrong bytes within the C Programming forums, part of the General Programming Boards category; Well, I have a strange problem with files. Basically what I'm trying to do is open 2 24-bit bmp files, ...

  1. #1
    Registered User
    Join Date
    Jan 2007
    Posts
    40

    writing wrong bytes

    Well, I have a strange problem with files. Basically what I'm trying to do is open 2 24-bit bmp files, compare their pixels, and write back out the pixels that remain the same and yellow pixels where they differ. This worked perfectly fine when I streamed the two files, but now I want to load the first file entirely into memory, and stream the second file. So I wrote the code to do this, and ran it, and oddly enough, a couple of the pixels wound up as strange offshoots of their original pixel, usually replacing one of the 3 color channels with 255. I suspect this to be a problem with overwriting memory, but can't for the life of me figure it out.

    Here's my code:

    Code:
    #include <stdio.h>
    
    //RGB pixel structure
    typedef struct {
     unsigned char c[3];
    } tCol;
    
    int main(int argc, char **argv) {
     FILE *f1, *f2, *t;
     tCol c1[480000], c2;
     unsigned char b[54];
     int n, s;
     f1 = fopen(argv[1],"rb");
     f2 = fopen(argv[2],"rb");
     t = fopen(argv[3],"wb");
    
     //skip header information
     fseek(f2,54,SEEK_SET);
     fread(b,54,1,f1);
     fwrite(b,54,1,t);
    
     s = fread(c1,3,480000,f1); //read file1 into buffer
     n = 0;
     while (fread(c2.c,3,1,f2) > 0) { //read file2 in pixel at a time
      if ((c1[n].c[0] != c2.c[0]) || (c1[n].c[1] != c2.c[1]) || (c1[n].c[2] != c2.c[2])) { //if pixel differs
       c1[n].c[0] = 0; //overwrite pixel in buffer with yellow
       c1[n].c[1] = 255;
       c1[n].c[2] = 255;
      }
      n++;
     }
     fwrite(c1,3,s,t); //flush buffer to file
    
     //if not an even 32 bits, add 0's to make it
     b[0] = 0;
     b[1] = 0;
     b[2] = 0;
     fwrite(b,s &#37; 4,1,t);
    
     fclose(t);
     fclose(f1);
     fclose(f2);
    }
    The images will never exceed 800x600, thus why I have hard coded in 480000.

    The image turns out perfect for an 800x600 image, but when I plug in a 54x32 image, a few pixels will suddenly go green, red, purple, blue, or teal when they're not supposed to, and usually they are to the left and right of or on an area that was supposed to turn yellow.
    Last edited by IsmAvatar2; 03-30-2007 at 01:50 PM.

  2. #2
    Registered User
    Join Date
    Oct 2001
    Posts
    2,934
    > tCol c1[480000], c2[0];
    For c2 that should be:
    Code:
     tCol c2[1];
    But there's no reason for c2 to be an array, so:
    Code:
     tCol c2;
    would suffice.

  3. #3
    Registered User
    Join Date
    Oct 2001
    Posts
    2,934
    And you might also have a problem with padding.
    Code:
    >typedef struct {
    > unsigned char c[3];
    >} tCol;
    The compiler could add padding to the end of this struct. Print out sizeof(tCol). If it does not print 3, then you have a problem.

  4. #4
    Registered User
    Join Date
    Jan 2007
    Posts
    40
    Not sure how that got to be 0, it used to be 1. I made it an array because it was complaining when I was trying to read it in from the file. But I made it stop complaining now so I can correct that.

    printf("&#37;i\n",sizeof(tCol));
    prints out 3 wherever I try it.

    The problem of the wrong bytes, though, still persists.
    Last edited by IsmAvatar2; 03-30-2007 at 01:46 PM.

  5. #5
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,672
    > but when I plug in a 54x32 image
    54 (the number of pixels in a row) * 3 (the number of bytes in a pixel) = 162
    This is not a multiple of 4

    Each row of a BMP is 4-byte aligned, which means there is two bytes at the end of each row you need to skip.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  6. #6
    Registered User
    Join Date
    Jan 2007
    Posts
    40
    Each row? Well that explains it. I thought it was just at the end of the file.
    Thanks. Guess I'll have to read the header information after all.

  7. #7
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,048
    If you need more information about the BMP format, search wotsit.org.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Rendering 32-bit images - alpha is ignored
    By ulillillia in forum Windows Programming
    Replies: 59
    Last Post: 04-21-2007, 03:50 PM
  2. strcat - cannot convert char to const char
    By ulillillia in forum C Programming
    Replies: 14
    Last Post: 12-07-2006, 09:00 AM
  3. Replies: 16
    Last Post: 10-29-2006, 04:04 AM
  4. God
    By datainjector in forum A Brief History of Cprogramming.com
    Replies: 746
    Last Post: 12-22-2002, 11:01 AM
  5. Reading Certain number of bytes from a file
    By (TNT) in forum Windows Programming
    Replies: 6
    Last Post: 01-14-2002, 07:35 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21