Page 1 of 1

Saving Problem with bit depth.

Posted: 2010-06-16T23:16:55-07:00
by wizards
Hi All.
I am using image magick library and visual C++ for my task.
I built image magick library with 16 bit.
I am loading JPEG image with the following properties.

Size:63.7 KB
Horizontal resolution: 72 dpi
Vertical Resolution: 72 dpi
Bit depth: 8 bit

After that i am applying some changes to image and then save image with the following code.

m_Image.type(TrueColorType);
m_Image.depth(8);
m_Image.write(FileName.GetBuffer(MAX_PATH+1));

After this my image properties will change into the following.

Size:69.7 KB
Horizontal resolution: 96 dpi
Vertical Resolution: 96 dpi
Bit depth: 24 bit

I am setting image bit depth as 8 bit, but it will change into 24 bit depth only.
How can i set same as orginal properties without any changes?

Please any one help me.

Thanks in advance.

Re: Saving Problem with bit depth.

Posted: 2010-06-17T06:10:59-07:00
by snibgo
I didn't know jpeg could store images with 24 bits per channel. Can you post a sample input and output file?

Re: Saving Problem with bit depth.

Posted: 2010-06-17T12:46:55-07:00
by Drarakel
The IM bit depth is a channel bit depth. The info that you get from the files (probably directly from Windows?) is a total image bit depth. When you set the type to TrueColor, you get a '24 bit' file (3x8bit - red, green and blue channel). Your original JPG was probably a greyscale (1x8bit) file. For a safe answer, you could provide the files, as snibgo said.

Re: Saving Problem with bit depth.

Posted: 2010-06-17T22:17:49-07:00
by wizards
Thanks for your responce.

I am posting input and output files.
Check the properties of these.

images:http://rapidshare.com/files/400262587/I ... s.zip.html

Re: Saving Problem with bit depth.

Posted: 2010-06-17T22:53:02-07:00
by snibgo
"identify" shows that both files are 8 bits per channel. InputImage.jpg is a palletted file, so has 8 bits per pixel. OutputImage.jpg is 3 channels ("TrueColor"), but all the pixels are gray.

Any of these:

convert InputImage.jpg -type Optimize o.jpg
convert InputImage.jpg -type Palette o.jpg
convert InputImage.jpg -type Grayscale o.jpg

will make a palletted output file. It saves very little space, because of the way jpeg compression works.

Re: Saving Problem with bit depth.

Posted: 2010-06-17T23:02:52-07:00
by wizards
I tried the following code for change Bit depth.
But No use...Image again save as 24 bit depth only.

m_Image.channelDepth(MagickLib::AllChannels, 8);

Re: Saving Problem with bit depth.

Posted: 2010-06-17T23:07:36-07:00
by snibgo
Why are you changing the channel depth? All these files have 8 bits per channel.

Are you still saving it as TrueColor? As I say above, this will give you three channels each of 8 bits.

Re: Saving Problem with bit depth.

Posted: 2010-06-17T23:23:19-07:00
by wizards
I removed type(truecolor), and tried..Its work good ...
Thankq..

Re: Saving Problem with bit depth.

Posted: 2010-06-17T23:53:57-07:00
by wizards
I removed type(TrueColorType), its work good for only 8 bit depth only.
Pleas help me..Which ImageType i will give in type()..
I tried
type(PaletteType), But its work only for 8bit depth and 32 bit depth images.Not for 24 bit depth images.

Re: Saving Problem with bit depth.

Posted: 2010-06-18T06:18:23-07:00
by Drarakel
@snibgo: JPG can't do palette. :wink:

@wizards: Again: Why are you messin' with the bit depth?
You shouldn't need to change the type when saving as JPG - unless you specifically want to reduce/change the colors.
A RGB image will typically be saved as full truecolor (3x8bit). When there are only greyscale colors, it will be saved as greyscale JPG (1x8bit). The only case where you might specify the type is when you have a greyscale image and want to save it as 3x8bit JPG (with '-type TrueColor').

Re: Saving Problem with bit depth.

Posted: 2010-06-18T11:25:10-07:00
by snibgo
@snibgo: JPG can't do palette.
Hmm, yes, you seem to be correct. I was being misled by "identify" which says "8-bit PseudoClass 256c" and shows a 256-entry colormap. But this may be IM deciding to transform a grayscale image into a palette file. Why would it do this? I don't know. Any suggestions?

For my statements above about "palletted [sic] file", read "grayscale file".

Re: Saving Problem with bit depth.

Posted: 2010-06-18T16:39:08-07:00
by Drarakel
Well, the info from identify is not false - but it's only for a representation of the image (of the data that IM has read in). It's not always the info from the actual file storage. Perhaps it's because IM tries to 'optimize' the data that got read in. That way, IM might be able to store some images in a more efficient way. But I have to say that sometimes it's still very complicated to create a file in a special 'optimized' way - e.g. as palette BMP or PNG. And in some cases, it even seems to create problems and you have to specify e.g. '-type Truecolor' to get the image you was expecting.
Personally, I don't take Class, Type, some of the depth info, the number of channels, and partly the 'colormap' info as something that one will find within the file exactly as displayed.
But I would be interested in a more detailed description of the behaviour, too.

Re: Saving Problem with bit depth.

Posted: 2010-06-21T05:06:09-07:00
by wizards
Hi...
I am beginner to the Image processing.
I'm sorry, i didn't get the above answer.

I'm Explaining clearly about my task.please help me..

I am using image magick library and visual C++ for my task.
I built image magick library with 16 bit.
I am loading different types of images(Like JPEG,BMP,PNG etc).
Then i'm writing image after read the image without any changes apply.

code:m_Image.read("C:\\Test\\test.jpg");
m_Image.write("C:\\Test\\test.jpg");

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.


For setting image resolution,i'm using the following code.
m_Image.density(Geometry(72,72));
even it will not effecting and agian it gives 96 dpi.

I want orginal properties without any changes, but here size,horizontal and vertical resolution were changed.
This only for 8 bit jpg image.

I observed the following iamges also.
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.
For 8bit BMP image(resolution 96 dpi),it gives 32 bit bmp with 95dpi resolution.
For 24bit BMP image(resolution 349 dpi),it gives 24 bit bmp with 349dpi resolution.
For 32bit BMP image(resolution 71 dpi),it gives 24 bit bmp with 71dpi resolution.etc..

I dont know the exact reason for this.I built image magick in 16 bit...this will create any effect for this changes?

I am sending all these input and output images.please check properties for all.
link:http://rapidshare.com/files/401295264/I ... s.zip.html

Please help me to get same properties for output image...

Thanking you in advance...

Re: Saving Problem with bit depth.

Posted: 2010-06-21T19:25:38-07:00
by Drarakel
My last post here was addressed to snibgo - not to you. :wink:

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'. :wink:
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.

Re: Saving Problem with bit depth.

Posted: 2010-06-21T22:25:16-07:00
by wizards
Hi Drarakel,

Thank you very much for your nice explanation.

Once again i will through all type of images with different bit depth and density and i will observe the outputs.

If i have any problem i will come back.


Once again thank you very much.