title: Error in writing certain bytes with fwrite()
body: <p>Certain things have changed since this was originally posted. I've marked them with an <strong>Edit</strong> header.</p>
  <p>I'm writing an image file from a source with a different format. This is data which is 1024x1024 and has 2 bytes per pixel.</p>
  <p>The source and destination image formats both consist of a header of a variable number of bytes(containing metadata such as the bytes per pixel etc) which is then followed by the Image data.</p>
  <p>Don't know if relevant, but we're using a 40+ year old software (called Mcidas) to display these images
  Previously, I read both bytes into an <code>unsigned short</code> array. Then some bit manipulations concatenated them to a new <code>unsigned short</code>. I then use the <code>fwrite()</code> function to write them into the target file.</p>
  <p><strong>Edit</strong><br />
  I'm now using <code>fread()</code> on <code>data</code> directly.</p>
  <p>The read operation is working well (tried both <code>fputc()</code> and <code>fread()</code>)</p>
  <p><strong>Edit</strong><br />
  The image data part of hexdumps of the two files completely match. However, for some reason, the image seems to show a bit error in certain bytes. The source file seems to be clean, too.</p>
  <p>Here's the Image (a 2MB file):<br />
  <a href="http://pdsimage.wr.usgs.gov/archive/mess-e_v_h-mdis-2-edr-rawdata-v1.0/MSGRMDS_1001/DATA/2007_156/EW0089565661F.IMG" rel="nofollow noreferrer">http://pdsimage.wr.usgs.gov/archive/mess-e_v_h-mdis-2-edr-rawdata-v1.0/MSGRMDS_1001/DATA/2007_156/EW0089565661F.IMG</a></p>
  <p>You could save this as &quot;source.IMG&quot; to test it.</p>
  <p>Below is a comparison of the source and final images, with a line scan done on the first line.</p>
  <p><a href="https://i.stack.imgur.com/MZ2k8.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/MZ2k8.png" alt="Source file and Image" /></a></p>
  
  <p>Note the sudden jumps for certain pixels, that give rise to contours. These seem to be about 256 in length, which leads us to suspect that there might be a flip of bits somewhere(the sign bit maybe?). The identical hexdumps indicate otherwise however.</p>
  <p>Here's the errant code:</p>
  <pre><code>#include&lt;stdio.h&gt;
  #include&lt;stdlib.h&gt;
  #include&lt;string.h&gt;
  int main()
  {
  unsigned char data_arr[2];
  unsigned short data;
  data=0;
  int pixel_per_line=1024;
  char path1[80]=&quot;source.IMG&quot;;
  char path[80]=&quot;destination&quot;
  fp=fopen(path1,&quot;rb&quot;);
  bin=fopen(path,&quot;wb&quot;);
  //fp points to the input file, bin to the output file.
  fseek(fp,8193,SEEK_SET);//sets the pointer to the relevant byte in the source file. 
  //A similar fseek() is used on bin in the original program
  while(!feof(fp))
  {
  //fflush(fp); (Removed the fflush()s now)
  int j;
  for(j=0;j&lt;pixels_per_line;j++)//iterate through all pixels in one line
          {
          for(int i=0;i&lt;2;i++)
              data_arr[i]=fgetc(fp);
          //data=(data_arr[0] &lt;&lt; 8) | data_arr[1];// bit manipulations done in the earlier version. 
          //This fails to give the right output.
           data=data_arr[0]*256 + data_arr[1]; // This switches alternate bytes. 
          if(fwrite(&amp;data,1,sizeof(data),bin)!=2) 
              printf(&quot;Write pains!&quot;);
          }
  //fflush(bin);
  }
  }
  </code></pre>
  <p><strong>EDIT</strong>:</p>
  <ol>
  <li><p>Added the <code>fopen()</code> statements and tested with <code>fflush()</code> removed, the error remains.</p>
  </li>
  <li><p>Added declaration for <code>unsigned short data</code></p>
  </li>
  <li><p>The code should run now.</p>
  </li>
  </ol>
  <p><strong>EDIT</strong></p>
  <p>Problem solved for the 2 byte image!
  All I did was switch alternate bytes. Look at the corrected code.
  I am not sure why it works though. Is it an endianness issue? Note that bitshifts did not work.</p>
  <p>I am having a similar problem for four byte images now. The data is stored as a floating point number. I <code>fread()</code> the bytes into a float, scale it and cast it into an integer. The results are similarly grainy. Permuting the bytes with bitshifts does not solve the problem.</p>
  <p>Can anyone throw some light on this?</p>