Save as BMP produces incorrect resolution

[johns32458848]

When I save bitmap file with 1 bit depth to .BMP, resolution of the resulting file becomes 72dpi regardless of original resolution. Actual dimensions in pixels are preserved, but decreasing the resolution causes dimensions in inches to be incorrect. When I save file manually, using save as dialogue there is no problem with the resulting resolution.

This is the code I am using to save. Is it possible to fix this problem and are you even able to reproduce it? Try creating a file with resolution  300/600dpi and running this function

function save() {  
    var saveBMP = new BMPSaveOptions();
    saveBMP = new BMPSaveOptions();
  //saveBMP.alphaChannels = false;
  saveBMP.depth = BMPDepthType.ONE;
  //saveBMP.flipRowOrder = false;
  //saveBMP.rleCompression = false;
  saveBMP.osType = OperatingSystem.OS2;
    app.activeDocument.saveAs( new File('~/Desktop/test.bpm'), saveBMP, true, Extension.LOWERCASE);  
}

Thank you

[JJMack]

That seems to happen when you use Photoshop UI as well.  When you have a 1bit bitmap image and save as bmp Photoshop may not set any dpi in the image file.

When Photoshop opens an image files that has no DPI setting I believe Photoshop will set the document dpi to 72 for it needs some setting to be able to work on the document many functions in Photoshop require the use of Photoshop document dpi setting.  You may want to use a  hex editor on the bmp file to see what is recorded decode in the image header.  There may be no setting be zero.....  I think save for web does the same for dpi is meaningless on the web so it set no setting into the files it saves.

The File Header

The File Header has exactly fourteen bytes separated into five fields.

Field Name	Size in Bytes	Description
bfType	2	The characters "BM"
bfSize	4	The size of the file in bytes
bfReserved1	2	Unused - must be zero
bfReserved2	2	Unused - must be zero
bfOffBits	4	Offset to start of Pixel Data

bfType

The first two bytes must be the ASCII codes for the characters 'B' and 'M'. The software should check these values to confirm that the file it is reading is most probably a Windows BMP file. There are actually other options for these two characters, but they all refer to formats developed for the OS/2 operating system, which is largely extinct.

bfSize

The second field is a four-byte integer that contains the size of the file in bytes. In theory, this means that a BMP file could be as large as 4GB (4,294,967,296 bytes), however it is not safe to assume that all editors will treat this as an unsigned value and therefore a more reasonable limit is 2GB (2,147,483,648 bytes). This can accommodate a 24-bit image that contains over 715 million pixels (e.g., a picture larger than 32,000 by 23,000 pixels). It is probably worth noting that the BMP file specification actually supports storing multiple images in a single file; however, this is almost never done and very few editors support this option.

bfReserved1

bfReserved2

The third and fourth fields are each two bytes long and are reserved for future extensions to the format definition. While certainly not impossible, it is unlikely at this point that either will ever be used. The present definition requires that both of these fields be zero. A well-written reader should behave reasonably if non-zero values are encountered, but what is "reasonable"? Should the reader ignore the values regardless of what they are, or should it refuse to proceed any further on the assumption that the file conforms to a later version of the format specification and that it has no basis for assuming that it can properly interpret the contents? Good arguments can be made for either approach. Assuming that the decision is made to go ahead and read the file while ignoring these values, what should happen when the file is written back to disk? Should these values be forced to zero, in order to conform to the present specification, or should they be preserved assuming that they have meaning to the program that originally generated the file? Again, good arguments can be made either way.

bfOffBits

The final four byte field is an integer that gives the offset of the start of the Pixel Data section relative to the start of the file.

---

The Image Header

The Image Header

There are actually several options for the Image Header, particularly when Versions 4 and 5 of the specification are considered. Limiting the discussion to Version 3, there are still two distinct options: one that was developed for the OS/2 BMP format and one that is for the Windows BMP format. The OS/2 Image Header is exactly 12 bytes long while the Windows Image Header is at least 40 bytes long. Fortunately, the first four bytes of each format (including Versions 4 and 5 and, probably, all future versions) is the length of the Image Header in bytes and therefore a simple examination of this value tells you which format is being used. While the Windows Image Header allows headers longer than 40 bytes (and this was supported by Windows 95), few applications ever adopted it and, once again, an editor that restricts itself to only working with 40-byte Image Headers will likely never encounter a file it can't work with.

The following is the format for the basic 40-byte Windows Image Header.

Field Name	Size in Bytes	Description
biSize	4	Header Size - Must be at least 40
biWidth	4	Image width in pixels
biHeight	4	Image height in pixels
biPlanes	2	Must be 1
biBitCount	2	Bits per pixel - 1, 4, 8, 16, 24, or 32
biCompression	4	Compression type (0 = uncompressed)
biSizeImage	4	Image Size - may be zero for uncompressed images
biXPelsPerMeter	4	Preferred resolution in pixels per meter
biYPelsPerMeter	4	Preferred resolution in pixels per meter
biClrUsed	4	Number Color Map entries that are actually used
biClrImportant	4	Number of significant colors

biSize

The size, in bytes, of the Image Header. Nearly all BMP files use the basic 40-byte header from the Windows Version 3 specification.

biWidth

This is the width of the image, in pixels.

biHeight

This is the height of the image, in pixels. The pixel data is ordered from bottom to top. If this value is negative, then the data is ordered from top to bottom.

biPlanes

This is the number of image planes in the image. It is always equal to 1.

biBitCount

This is the number of bits used to represent the data for each pixel. Bit Counts of 8 or less are "indexed" with the data being an index into the color pallete that is located stored in the Color Table section. Bit Counts greater than 8 are considered to be "true color" data with the complete color information being contained in each pixel's data. The overwhelming number of true color BMP files contain 24-bit images in which each pixel is represented by three bytes of data with one byte each for red, green, and blue intensities; no Color Table is present for such an image. Bit counts of 16 and 32 are color-masked bit fields and although all of the color data is present for each pixel, a set of three bit-masks, one for each primary color, is needed in order to determine which bits correspond to which colors; these bitmasks are stored in the Color Table section (with a default set of color masks being used if no Color Table is present).

biCompression

This value indicates what type of compression, if any, is used. The possible values are:

biCompression	Meaning
0	Uncompressed
1	RLE-8 (Usable only with 8-bit images)
2	RLE-4 (Usable only with 4-bit images)
3	Bitfields (Used - and required - only with 16- and 32-bit images)

biSizeImage

This indicates the size of the actual pixel data, in bytes, stored in the file. It is required for compressed image types. For uncompressed types (including bit-fielded images) it is generally set equal to zero since the size of the data can be calculated directly from the image size and width.

biXPelsPerMeter

This is the preferred horizontal resolution of the image, in pixels per meter, when it is printed or displayed. It is only recommendation to the display device and is generally equal to zero, indicating no preference.

biYPelsPerMeter

This is the preferred vertical resolution of the image, in pixels per meter, when it is printed or displayed. It is only recommendation to the display device and is generally equal to zero, indicating no preference.

biClrUsed

This value is zero except for indexed images using fewer than the maximum number of colors, in which case it refers to the number of colors contained in the Color Table. For the indexed bit depths (i.e., Bit Counts of 8 and smaller) the Color Table contains a list of colors to which the pixel data refer. The maximum number of colors that can be used is 2^N where N is the value of Bit Count. For instance, 8-bit images can support a maximum of 256 colors. But suppose that an image only uses 47 colors. Why store 256? More to the point, why have to make up 109 colors that aren't being used? Instead, simply set this parameter to 47 and store those 47 colors and no more.

In practice it is very uncommon to run across images that have anything other than zero for this parameter. The reason is that it is a simple matter to go ahead and set all of the unused colors to all zero (black) -- or some other color -- and store all 2^N of them in the Color Table. The space penalty is negligible since the file size is dominated by the pixel data for all but the smallest images.

biClrImportant

This is the number of colors that are considered important when rendering the image. For instance, an image might contain 47 different colors but perhaps a reasonable image can be generated using just 13 of them. If the image is displayed on hardware having very limited color capability, say a cheap LCD panel supporting only 16 colors, then the reader knows that it should be able to generate an acceptable image by just using the first 16 colors in the Color Table. Needless to say, the important colors need to be stored first in the Color Table for this to work. It is left up to the application reading the file to determine how to map the "unimportant" colors into the available ones.

If this parameter is equal to zero, then all colors in the Color Table are to be considered important.

[Kukurykus]

I use Windows, but when I created document with 600 ppi and wanted to save it manually I could choose only between 16, 24, and 32 depths, while other options were unavailable. If I used your script it prompted me of the same thing. When I set displayDialogs = DialogModes.NO, error occured. What is your document that it let you choose ONE, manually or by script?

[johns32458848]

The document color mode has to be bitmap. It has to be first converted to grayscale, then to bitmap.

[Kukurykus]

That's probably bug, becuase when you change OS to WINDOWS script saves a bmp file with its current resolution. I saved it also manually, and it is not like you say that you may keep original resolution with .OS (however you didn't mention you use it or .WINDOWS doing it manually). Exactly like with using script when I choose .OS it changes resolution to 72 px / in. But when I use .WINDOWS, whatever by script or manul, resolution is preserved.

I compared files saved with .WINDOWS and .OS, and basicly they are the same (Document Size for ex. in CM). Workaround is to with each opening of such file (when it's already saved as .bmp) run another script which will be changing 72 resolution to desired. It's going to proportionally increase dimension (pixels, while cm will remain as was) you have to retrieve to width and height that it had before .bmp saving. That won't change neither resolution nor document size, while you keep quality.

Other way is to read binary's of .bmp (not opened in Ps) to rewrite resolution and width & height to be properly displayed.

[JJMack]

Did you look at the Image header saved by Photoshop for your 1bit BMP file is any resolution stored in there or is it zero?