My last post here was addressed to snibgo - not to you.
Regarding your problems with the properties:
wizards wrote:I want orginal properties without any changes, but here size,horizontal and vertical resolution were changed.
First: As you are writing/recompressing new files, there's nothing unusual in the change of the file size. (Especially not for JPG which is a lossy format - so here, you'll also degrade the image a bit with every writing.)
Then: The properties that you seem to expect is only the info from Windows Explorer. You won't always get precise information from images there - so forget your 'original properties'.
And you shouldn't worry about the file properties that much as long as you're getting the same image data - which is always the case here (except for JPG of course - and one BMP, but I will come back to that later).
The DPI info can be complicated sometimes (not so much with BMP, but e.g. with JPG) - but do you really need these values?
If you need more details:
wizards wrote:For 8bit BMP image(resolution 96 dpi),it gives 32 bit bmp with 95dpi resolution.
No - both images are 8bit palette BMPs with about 96dpi.
The first one is uncompressed, the second one with RLE compression. (The default for ImageMagick when it writes 8bit palette BMPs is to use RLE compression. You can turn it off with '-compress none'. But it won't make a difference in your example - except for file size.) Windows Explorer simply displays a wrong depth info with such files.
The density in BMP files is always stored in pixels per meter. IM does change the value a bit in this example, but not by a full 1 dpi - only by 0.02 dpi. To be precise, the horizontal and vertical density values in the input file are 0xEC4 (which is approx. 96.01 dpi). In the output file, it's 0xEC3 (which is approx. 95.99 dpi). I'm not completely sure why that happens (probably some internal conversions are involved), but both values are ok. IrfanView for example reports both files as 96dpi.
wizards wrote:For 24bit BMP image(resolution 349 dpi),it gives 24 bit bmp with 349dpi resolution.
24bit (3x8bit) BMPs with 350dpi. (Windows Explorer just can't round.)
wizards wrote:For 32bit BMP image(resolution 71 dpi),it gives 24 bit bmp with 71dpi resolution.etc..
Input: 32bit (3x8bit + 8bit for alpha layer) with 72dpi; Output: 24bit (3x8bit) with 72dpi
This is the one exception where you will lose a part of the image (the alpha layer). But a 32bit RGBA Bitmap is a bit unusual (can be debated if it's an official format). At the moment, ImageMagick only supports an alpha layer in BMPs if the files have a V4 or V5 header - not if the file has a Windows V3 header (like yours). You will have to convert this file to another format with programs like Gimp or XnView if you need the alpha layer.
wizards wrote:If i will give 24 bit jpeg image (resolution 96 dpi) as input,then i got 8bit image as output and resoultion is 100 dpi.
The input file is stored with 3x8bit, but has only greyscale pixel values. As i wrote earlier here, ImageMagick will store the output file directly as greyscale JPG (1x8bit) in such cases. You can disable it by adding '-type TrueColor' (commandline), but I don't see a reason for doing this here.
The density value in both files is always '100' (specified in the JFIF header). But the input file hasn't set any unit value for it (which can be PixelsPerInch, PixelsPerCentimeter or undefined). In such cases, the Windows Explorer probably ignores the density values from the file (and displays the Windows default of 96dpi). ImageMagick however seems to use 'PixelsPerInch' as default here and writes this into the output file. Thus, the output file is recognized as 100dpi in all programs.
wizards wrote:I am loading JPEG image with the following properties.
width: 432 pixels
height: 431 pixels
Size: 63.7 KB
Horizontal resolution: 72 dpi
Vertical Resolution: 72 dpi
Bit depth: 8 bit
my output image properties will change into the following.
width: 432 pixels
height: 431 pixels
Size:69.7 KB
Horizontal resolution: 96 dpi
Vertical Resolution: 96 dpi
Bit depth: 8bit.
Is this a description for case '8bit.jpg'? The input file here is a 8bit greyscale JPG, but you seem to have included a different output file. I don't think this was written with ImageMagick - probably with Adobe Photoshop or something.. If I convert the input file with ImageMagick, I get another 8bit greyscale JPG with 72dpi.
Your posted output '8bit.jpg' is a modified 24bit JPG (3x8bit with only greyscale values) with, well, 72dpi. The Windows Explorer shows it as 96dpi, because the density values in the Exif profile have also been modified. The Exif values can lead to confusion as these are stored with a.. numerator and denominator and are sometimes updated wrongly. In this file, they're stored as 72/10000 - for Windows Explorer (which takes the Exif values in JPGs - if there are none, it takes the normal header values) that equals 0. If Windows Explorer reads 0 or nothing as density value, it shows the default of 96.
By the way, if you convert this output file with IM with '-density 72', the header and Exif values get updated (the Exif values get stored as 72/1). Then, even Windows Explorer reads it as 72dpi. Oh.. and besides JFIF header and Exif profile, density values are also stored in the Photoshop profile and XMP profile in your '8bit.jpg' files (IM doesn't update these).
But if you only want to change density values and nothing in the image itself, IM wouldn't be the right tool for JPGs - as it always has to recompress the files.
As I said, the density can be a bit complicated.