Binary file: hitting eof too soon?

Alotau · #1 18-May-2004, 09:33

Howdy,

I am working with a binary file for the first time. It is a .pgm and I need to to some image processing/compression stuff with it. My problem seems to be that as I am reading in a file, it hits the eof way too soon. I put in some checks to verify this (infile.eof()). I know exactly how big the file is, so I know this shouldn't be the end. Here is some code I am using:

CPP / C++ / C Code:

const int  NAME_SIZE  = 30;
const int  BLOCK_SIZE = 32;
const int  WIDTH	  = 256;

fstream infile, outfile;
char inFileName[NAME_SIZE];
char outFileName[NAME_SIZE];
char buffer[BLOCK_SIZE * WIDTH];

cout << "\nEnter the name of the .pgm file to quantize: ";
cin.getline(inFileName, NAME_SIZE - 1, '\n'); //smiley doesn't go here... interpreted my code.
	
infile.open(inFileName, ios::in | ios::binary);
if(!infile)
{
	cout << "Can't find named file.  Try again\n";
	return 0;
}

strcpy(outFileName, inFileName);
strcat(outFileName, ".qua");
outfile.open(outFileName, ios::out | ios:: binary);

for(int rows = 0; rows < WIDTH/BLOCK_SIZE; rows++)
{
             infile.read(buffer, sizeof(buffer));
             cout << "Tried to read " << BLOCK_SIZE * WIDTH << " bytes." << endl;
	cout << "# bytes actually read:  " << infile.gcount() << endl;
	cout << "Curr pointer on infile: " << infile.tellg() << endl;
	cout << "good() = " << infile.good() << endl;
	cout << "eof()  = " << infile.eof()  << endl;
	outfile.write(buffer, sizeof(buffer));
}

The output looks like this (the pointer is a little off because I read the header of the file separately first):

Enter the name of the .pgm file to quantize: goldhill.pgm
Tried to read 8192 bytes.
# bytes actually read: 8192
Curr pointer on infile: 8271
good() = 1
eof() = 0
Tried to read 8192 bytes.
# bytes actually read: 8192
Curr pointer on infile: 16463
good() = 1
eof() = 0
Tried to read 8192 bytes.
# bytes actually read: 8192
Curr pointer on infile: 24655
good() = 1
eof() = 0
Tried to read 8192 bytes.
# bytes actually read: 5615
Curr pointer on infile: -1
good() = 0
eof() = 1
Tried to read 8192 bytes.
# bytes actually read: 0
Curr pointer on infile: -1
good() = 0
eof() = 1
...then it does that a few more times. The file is 256X256 pixels (8bpp), so I know it should keep going.

Sorry I didn't know how to format the code on this posting (my first one!). Any advice is appreciated.

Is it just that the file happens to have an eof char within it, so the read stops?

dsmith · #2 18-May-2004, 09:48

Hello Alotau. Welcome to GIDForums. I have editted your post to highlight the c-syntax. It is done with c and /c tags enclosed by []. Read the first sticky of this sub-forum for more info.

I had the exact same problem with binary files. Since EOF is just an ASCII character (I can't remember the value right now), it occurs quite often in binary files by chance. So, AFAIK, EOF does not work to check for the end of a file when using binary files.

My work around is to get the file size and use that to track where the end of the file really is. This has worked perfectly in my programs.

HTH,
d

Alotau · #3 18-May-2004, 10:11

Quote:

Originally Posted by dsmith

AFAIK, EOF does not work to check for the end of a file when using binary files.

Thanks for the quick response! I am using the streams in binary mode and I know the size of the file is a bit over 64K, so it still doesn't make sense to me why the eof flag gets set somewhere in the middle of the file. Will it make any difference if I read the whole file at once and then break it into blocks for processing? (Don't see why it should.) Any further advice appreciated....

What is the quickest way to verify file size from within the program?

dsmith · #4 18-May-2004, 11:09

Quote:

Originally Posted by Alotau

Thanks for the quick response! I am using the streams in binary mode and I know the size of the file is a bit over 64K, so it still doesn't make sense to me why the eof flag gets set somewhere in the middle of the file. Will it make any difference if I read the whole file at once and then break it into blocks for processing? (Don't see why it should.) Any further advice appreciated....

What is the quickest way to verify file size from within the program?

Hi again Alotau. We have talked about this before in this thread. For the record, I don't 100% agree with Walt that the eof will work. But to be honest all of my file stuff for my own programs is done with stdio and I am sure that feof does not work here.

As for the file size, you can look at this post here. Unfortunately that is somewhat *nix specific. If you are using windows depending upon which libraries you want to use, you could do something similar or use the Windows API.

HTH,
d

machinated · #5 18-May-2004, 12:56

Quote:

Originally Posted by dsmith

I had the exact same problem with binary files. Since EOF is just an ASCII character (I can't remember the value right now), it occurs quite often in binary files by chance. So, AFAIK, EOF does not work to check for the end of a file when using binary files.

My work around is to get the file size and use that to track where the end of the file really is. This has worked perfectly in my programs.

HTH,
d

true that eof is an ascii character, and it occurs often in binary files but im sure that the fstream.eof function works perfectly for all files as i dont think it checks for the eof character itself, but rather gets the end of file some other way probably through the sytem. Or maybe im wrong

Alotau · #6 18-May-2004, 13:43

Thanks again for helping me out with this. I added a couple of lines of code that precede the above accesses to the file to verify that the file I am reading is actually of the length I thought it was, and the result still leaves me confused.

The lines I added were:

CPP / C++ / C Code:

infile.seekg(0, ios::end);
	cout << "The end of the file is: " << infile.tellg() << endl;
	infile.seekg(0);

And the results were the same. Note that the eof flag gets set when I am less than 30K bytes in:

Enter the name of the .pgm file to quantize: goldhill.pgm
The end of the file is: 65614
Tried to read 8192 bytes.
# bytes actually read: 8192
Curr pointer on infile: 8271
good() = 1
eof() = 0
Tried to read 8192 bytes.
# bytes actually read: 8192
Curr pointer on infile: 16463
good() = 1
eof() = 0
Tried to read 8192 bytes.
# bytes actually read: 8192
Curr pointer on infile: 24655
good() = 1
eof() = 0
Tried to read 8192 bytes.
# bytes actually read: 5615
Curr pointer on infile: -1
good() = 0
eof() = 1
Tried to read 8192 bytes.
# bytes actually read: 0
Curr pointer on infile: -1
good() = 0
eof() = 1
Tried to read 8192 bytes.
# bytes actually read: 0
Curr pointer on infile: -1
good() = 0
eof() = 1
Tried to read 8192 bytes.
# bytes actually read: 0
Curr pointer on infile: -1
good() = 0
eof() = 1
Tried to read 8192 bytes.
# bytes actually read: 0
Curr pointer on infile: -1
good() = 0
eof() = 1

I looked at the threads suggested--thanks. But they didn't quite address this issue. I'll keep hacking away at this, but any more suggestions?

machinated · #7 18-May-2004, 14:00

thats funny because i ran the program on my computer and i used a 64k jpg file and created an identical copy of it with .jpg.qua extension. This is the output:

Enter the name of the .pgm file to quantize: sunset.jpg
Tried to read 8192 bytes.
# bytes actually read: 8192
Curr pointer on infile: 8192
good() = 1
eof() = 0
Tried to read 8192 bytes.
# bytes actually read: 8192
Curr pointer on infile: 16384
good() = 1
eof() = 0
Tried to read 8192 bytes.
# bytes actually read: 8192
Curr pointer on infile: 24576
good() = 1
eof() = 0
Tried to read 8192 bytes.
# bytes actually read: 8192
Curr pointer on infile: 32768
good() = 1
eof() = 0
Tried to read 8192 bytes.
# bytes actually read: 8192
Curr pointer on infile: 40960
good() = 1
eof() = 0
Tried to read 8192 bytes.
# bytes actually read: 8192
Curr pointer on infile: 49152
good() = 1
eof() = 0
Tried to read 8192 bytes.
# bytes actually read: 8192
Curr pointer on infile: 57344
good() = 1
eof() = 0
Tried to read 8192 bytes.
# bytes actually read: 8192
Curr pointer on infile: 65536
good() = 1
eof() = 0

how big is your file?
I just noticed that your program only reads up until 64k but it does it perfectly

machinated · #8 18-May-2004, 14:22

i just tried your program on a .mp3 file which is 3,797,543 bytes in size.
3,797,543/8192 = 463.5672607. So i first ran your loop like so:

for(int rows = 0; rows < 463; rows++)

and it displayed the following results (im pasting the few lines at the end)
Tried to read 8192 bytes.
# bytes actually read: 8192
Curr pointer on infile: 3776512
good() = 1
eof() = 0
Tried to read 8192 bytes.
# bytes actually read: 8192
Curr pointer on infile: 3784704
good() = 1
eof() = 0
Tried to read 8192 bytes.
# bytes actually read: 8192
Curr pointer on infile: 3792896
good() = 1
eof() = 0
Press any key to continue

as you can see that eof was 0 and good was 1 till the end.

then i ran the program with this loop:

for(int rows = 0; rows < 464; rows++)

this time it gave the following results (im just pasting few lines at the end of the display)

Tried to read 8192 bytes.
# bytes actually read: 8192
Curr pointer on infile: 3784704
good() = 1
eof() = 0
Tried to read 8192 bytes.
# bytes actually read: 8192
Curr pointer on infile: 3792896
good() = 1
eof() = 0
Tried to read 8192 bytes.
# bytes actually read: 4647
Curr pointer on infile: -1
good() = 0
eof() = 1

as you can see, as soon as the entire 3.62mb file is over, eof sets to 1 and good sets to 0. This proves that eof() function works as expected and it actually sets to true when it detects the true end of file and not the end of file character. Hope this helped. BTW great little program

Alotau · #9 18-May-2004, 14:27

Quote:

Originally Posted by machinated

thats funny because i ran the program on my computer and i used a 65k jpg file and created an identical copy of it with .jpg.qua extension...
...how big is your file?
I just noticed that your program only reads up until 64k but it does it perfectly

Thanks for giving it a try. It is exactly a 256X256 pixel image (8bpp), so it is programmed to read in 8 32X32 pixel chunks. I read the header to the .pgm file separately before going into this code so all that there is to read is the 64K image.

So, why would my file cause problems? Wish I could attach the .pgm file, but not a valid file type for upload here...

machinated · #10 18-May-2004, 14:29

just manually rename ur file to .jpg and upload it

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Rate This Thread
Rate This Thread:

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
CD burner wont burn!!	robertli55	Computer Hardware Forum	1	18-Jun-2004 10:53
Yet another CD burner problem: Lite-On LSC-24082K	Erwin	Computer Hardware Forum	1	22-May-2004 11:28
Can't view pages from another machine on the Intranet	aevans	Apache Web Server Forum	9	14-May-2004 02:26
Help with binary files (encryption?)	pablowablo	C++ Forum	6	28-Apr-2004 22:47
Re: Programming Techniques	WaltP	C Programming Language	0	09-Mar-2004 23:56