This project has moved and is read-only. For the latest updates, please go here.

BPP

Jan 28, 2015 at 5:08 PM
I give up. Why is finding the Bits Per Pixel so difficult? What am I missing? Depth returns 8 on a 24 BPP image. That's fine if i have a channel property that I can multiply it by but I don't see that either. So please tell me how to find the bits per pixel.

Thanks,
Darren
Jan 28, 2015 at 10:41 PM
8 is the bits per channel. You cannot get the number of channels at this moment. I could add a property to MagickImage that would return the Channels that are available in the image. What do you think of the following?
public class MagickImage
{
  IEnumerable<Channels> Channels
  {
    get;
  }
}  
And would you mind sharing why you need the BPP?
Jan 29, 2015 at 1:12 PM
While that would be helpful it wouldn't immediately solve my problem. If it were changed to return an int of the Count of Channels it would help. At least then I could get the Depth * the ChannelCount to get BPP.

The reason I want BPP is:
  1. It's available in most imaging toolkits so it's very commonly used. That's why i was shocked not to be able to find it anywhere.
  2. My specific need is to filter out all images below 24bpp from a list.
Right now I have kind of a hack-ish solution with this code.
    int colorType = (int)Convert.ChangeType(curImage.ColorType, curImage.ColorType.GetTypeCode());
    bool isTrueColor = colorType >= 6 && colorType <= 9;
    ColorSpace cs = curImage.ColorSpace;
I'm just using the bool right now but I put the ColorSpace in to double check. Just trying to find something that would work.

Thanks,
Darren
Jan 29, 2015 at 1:54 PM
I thought IEnumerable<Channels> would be more useful because it will tell you which channels the image contains. And with the help of Linq you can do the following:
using (MagickImage image  = new MagickImage("logo:"))
{
  int bbp = image.Depth * image.Channels.Count();
}
p.s. Contact me through CodePlex if you would like a development build with this feature.
Jan 29, 2015 at 7:23 PM
I'm fine with your suggested change. It's easy enough. I hadn't considered Channels.Count().
Feb 9, 2015 at 1:58 PM
Edited Feb 9, 2015 at 2:26 PM
FYI - I tested your change and it works however on a CMYK image the channels are called Red, Green, Blue, Black. I'm not sure that's intended or not. For my use it doesn't matter.


Thanks,
Darren
Feb 9, 2015 at 2:02 PM
This is happening because the enumeration has the same value for Red as Cyan. There is nothing I can do about that :)
Feb 9, 2015 at 2:26 PM
Sorry - i didn't see your response. Here's my previous edit.

--update
I take it back. It mostly works but on SRGB 256 color 8-bpp it's returning 48-bpp because for some reason it thinks the images are RGB and 16-bpc. See this image as an example https://app.box.com/s/kw3j7mvch7m7llhtlbe9xyif507mv17p

This is what tiffinfo thinks of the image.
tiffinfo del-081314_DFW_P1_TEX_SR_v1_I4.tif
TIFF Directory at offset 0x34 (52)
Image Width: 94 Image Length: 10
Resolution: 300, 300 pixels/inch
Bits/Sample: 8
Compression Scheme: AdobeDeflate
Photometric Interpretation: palette color (RGB from colormap)
Samples/Pixel: 1
Rows/Strip: 10
Planar Configuration: single image plane
Color Map: (present)
Feb 10, 2015 at 7:01 PM
This image is a bit confusing because it has a color map that uses 16-bits per channels. And with 3 channels this totals to 48-bpp. This is different from how the image is stored on disk. Each 8 bits of a pixel points to a color in the color-map and that is why tiffinfo reports it as 8 Bits/Sample.
Feb 13, 2015 at 5:31 PM
Would you mind explaining how you came to that conclusion so I can investigate it myself please?

Thanks,
Darren
Feb 13, 2015 at 6:17 PM
I stepped through the code of ImageMagick where the tiff coder loads the colormap (TIFFTAG_COLORMAP). The colormap contains values higher then 255 which makes this images 16*3 (RGB) bit.
Feb 19, 2015 at 2:34 PM
Dirk,
But it seems that the TIFF file is created properly according to the TIFF Spec. This is from "Section 5: Palette-color Images".
PhotometricInterpretation = 3 (Palette Color).

ColorMap
Tag     = 320 (140.H) Type   = SHORT
N         = 3 * (2**BitsPerSample)

This field defines a Red-Green-Blue color map (often called a lookup table) for palette color 
images. In a palette-color image, a pixel value is used to index into an RGB-lookup table. For 
example, a palette-color pixel having a value of 0 would be displayed according to the 0th Red, 
Green, Blue triplet.

In a TIFF ColorMap, all the Red values come first, followed by the Green values, then the Blue 
values. In the ColorMap, black is represented by 0,0,0 and white is
represented by 65535, 65535, 65535.
So if it's created right I'm not sure why IM.Net is not reporting it right. Maybe my ignorance is too great here?

Thanks,
Darren
Feb 19, 2015 at 6:42 PM
It is reporting it correctly. 65535 is the maximum value of an unsigned short which is 16-bit. And this is how a color is represented in the color map. 3 times 16-bit = 48-bit.
Feb 20, 2015 at 3:46 PM
I don't understand Dirk. According to the spec every Palette Color image that has white will be represented as 65535, 65535, 6553. That doesn't mean every Palette Color image is 48-bit. My image is 8-bit and not 48-bit.
Feb 20, 2015 at 10:01 PM
Your image uses 8-bits to store the index in the color palette. You might consider this image 8-bit but ImageMagick looks at the bits that are necessary to represent one pixel. Each channel in the color palette uses 16-bits to store a value. Your image has 3 channels which totals to 48-bit.