Binary read write problem 1

[fabien]

Hi!

Following on my previous post:

http://www.tek-tips.com/viewthread.cfm?qid=982641&page=1

I have a read function like this:

 /* open file */
  fstream  file (filename, ios::in | ios::binary);

if (!file)
{
   PRINT_ERROR("Cannot open file (%s)\n",filename);
} 
  
  file.seekg (0, ios::beg);
  /* read dimensions */
  file.read(&hi,1);
  file.read(&lo,1);
  lenx = hi*256+lo;
  file.read(&hi,1);
  file.read(&lo,1);
  leny = hi*256+lo;
  file.read(&hi,1);
  file.read(&lo,1);
  lenz = hi*256+lo;
 
   pixels = new GLubyte [lenx * leny * lenz];

if (pixels==NULL)
{
   PRINT_ERROR("Read_data() : Out of memory (%s)\n",filename);
}
 /*read data*/
 file.read(pixels,lenx * leny * lenz);

I have implemented a write function like this

GLint hi = 0;

 /* open file */
  fstream  file (filename, ios::out | ios::binary);

  /* write dimensions */
  file.write(reinterpret_cast <char*> (&hi),1);
  file.write(reinterpret_cast <char*> (&lenx),1);
  file.write(reinterpret_cast <char*> (&hi),1);
  file.write(reinterpret_cast <char*> (&leny),1);
  file.write(reinterpret_cast <char*> (&hi),1);
  file.write(reinterpret_cast <char*> (&lenz),1);

  /*write data*/
 file.write(reinterpret_cast <char*> (&pixels),lenx * leny * lenz);

Everything works fine execpt that if I call the write function straight after the read the out file file is smaller than the input file: 1048582 vs 1376262 resp.I check lenx, leny and lenz are the same (128,128,64) resp

Any ideas why?

Thanks!

 

[Salem]

> file.read(&hi,1);
> file.read(&lo,1);
hi and lo are unsigned char right?

There are a couple of things wrong with your write code.

> file.write(reinterpret_cast <char*> (&hi),1);
> file.write(reinterpret_cast <char*> (&lenx),1);
It is an assumption that the least significant byte of lenx is also at the lowest address in memory (the address you get with that pointer expression).
You should really reverse the calculation you did in the reading code.

  lo = lenx % 256;
  hi = lenx / 256;
  file.write(reinterpret_cast <char*> (&hi),1);
  file.write(reinterpret_cast <char*> (&lo),1);

> file.write(reinterpret_cast <char*> (&pixels),lenx * leny * lenz);
You're writing from where the pointer is stored, not where the pointer points.
Sure you get a block of data written to the file, but it's not your data.

file.write(reinterpret_cast <char*> (pixels),lenx * leny * lenz);

> the out file file is smaller than the input file:
Well according to the information you've provided, this is correct.
Perhaps there's something else you're supposed to be reading (and writing) to make up all the extra data.

Is there a web reference documenting this file format?

--

 

[fabien]

Thanks Salem,

I did that and got the same size. it is certainly something in

file.write(reinterpret_cast <char*> (pixels),lenx * leny * lenz);

pixels are of type GLuByte.

RE web reference this format is known as "virvo" .rvf see

http://www.cs.brown.edu/people/schulze/projects/vox/release/deskvox2_00b.txt

 

[Salem]

Do you have any other programs which can read (and validate) those file contents.

From the spec, you seem to be doing the right thing.

"This format can easily be created by hand" - this isn't a good sign, leads me to suspect that the header itself is wrong, and there's nothing wrong with the code you posted.

--

 

[fabien]

could it be the type of the data I export? When I import it I convert the data to (char*) in file.read((char*)pixels,lenx*leny*lenz) (the input code I wrote an old version now I cast with (char*))
As I said before pixels are declared as GluByte

when I write the data to disk I cast the data with (char*).

 

[xwb]

Does it work if you do it in C? i.e.

FILE* handle;
handle = fopen (filename, "rb");
fread (&hi, 1, sizeof (hi), handle);
fread (&lo, 1, sizeof (lo), handle);
...

fclose (handle);

 

[fabien]

no same result.

 

[fabien]

Actually I tried with some other data and now I am getting the same size in and out. There must have been something strange with the file itself (extra chunk of info written?)

Coming back to the format itself 3 x 2 byte (big endian) for the header what does :

 lenx = hi*256+lo;

and

 lo = lenx % 256;

do exactly?

Thanks