Bug converting from jpg to bmp

[cam]

Hi,

i use this command to convert file formats:

convert hi.jpg hi.bmp

and everything went okay, but the hi.bmp file siz is 75000054 bytes and if you open it the File size of the Image Header says 75000154 bytes, when i convert the same jpg image to bmp with photoshop or gimp the file size match exactly with the file size of the bmp file header (3-6 bytes from the begin of the file).

what is going on? thank you.

[snibgo]

What version of IM are you running? On IM v6.8.7-0, Windows 7, I get the correct bfSize.

[cam]

I am using this version:

Version: ImageMagick 6.8.7-8 Q8 i686 2013-12-01 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2014 ImageMagick Studio LLC
Features: DPC OpenMP
Delegates: bzlib djvu fontconfig freetype jng jp2 jpeg lcms lqr openexr pangocairo png tiff x xml zlib

It is rare that the file size in the file header is bigger than the real size in the image at disk.

[fmw42]

Post a link to your image so others can check it. You can post to dropbox and put a link here.

[glennrp]

Using one of my own JPG files as source, I get a slightly smaller internal "file_size" than that shown by "ls -l",
and it varies a little depending upon the BMP format that was written. In each case, the real file size is the
internal file_size + BMP_size + 14. Extract from -debug output:

• bmp2:
  BMP size: 12
  Format: OS/2 Bitmap
  Reading pixels (30108672 bytes)
  -rw-rw-r-- 1 glennrp glennrp 30108698 Dec 9 11:44 4240bmp2.bmp
  
  bmp3:
  BMP size: 40
  Format: MS Windows bitmap
  Reading pixels (30108672 bytes)
  -rw-rw-r-- 1 glennrp glennrp 30108726 Dec 9 14:46 4240bmp3.bmp
  
  bmp4:
  BMP size: 124
  Format: MS Windows bitmap
  Reading pixels (30108672 bytes)
  -rw-rw-r-- 1 glennrp glennrp 30108810 Dec 9 11:55 4240bmp4.bmp

I added another line of debug output to show the file_size as read by our bmp decoder:

• bmp2:
  File_size in header: 30108698 bytes
  bmp3:
  File_size in header: 30108726 bytes
  bmp4:
  File_size in header: 30108810 bytes

As you can see, they agree exactly with the actual file size according to "ls -l".