PixelTypeInfo could use a BitsPerComponent property

[0xC0000054]

Currently the only method to determine the image bit-depth when using Identify is to guess based on the value of the BitsPerPixel property.
The BitsPerPixel property can be ambiguous for some image formats, e.g. L16 and La16 have the same number of bits-per-pixel.

A BitsPerComponent property would allow callers to determine the image bit depth without any guesswork.

This would simplify the case where a caller does not know in advance if the image is 8-bits-per-component or 16-bits-per-component.

[JimBobSquarePants]

The idea behind the current API is that further information is obtainable upon demand.

For example if you use.

Image.Identify(stream, out IImageFormat detectedFormat)

Then you can use the returned format to determine other format specific metadata.

if (detectedFormat is PngFormat pngFormat)
{
    PngMetadata pngMeta = imageInfo.Metadata.GetPngMetadata();

    PngColorType? colorType = pngMeta.ColorType;
}

You can then use that returned value to tell you whether the original pixel format contains an alpha component.

[0xC0000054]

@antonfirsov

A/ What is your application, and how does it use the information about the bit depth?

I use the bit depth to determine if the image should be loaded as Rgba64 or Rgba32.

B/ Do you have some prior knowledge on the images being fed to Identify? (Eg. all of them are PNG-s.)

No, it could be any format.

C/ What about a case when it's not possible to match the native pixel format?

Then it will be converted to Rgba64 or Rgba32.

[antonfirsov]

@JimBobSquarePants I wouldn't add an extensible (!) list of new properties on IPixel, because (1) it's already too heavy. (2) Pixel and Pixel Type/Format are really different domain model terms. I believe the right way of separating these concerns is to distinguish them on type system level. WIC has a similar abstraction:
https://docs.microsoft.com/en-us/windows/win32/api/wincodec/nn-wincodec-iwicpixelformatinfo

[...] so it can be read by any TPixel method.

A way to get a PixelTypeInfo for a generic TPixel type argument could be as simple as default(TPixel).GetPixelTypeInfo() or PixelOperations<TPixel>.Instance.GetPixelTypeInfo()

[JimBobSquarePants]

If you don't enforce it as a contract how do you ensure that all TPixel implementations return the correct value? Or do you mean add the GetPixelTypeInfo method to the interface?

[antonfirsov]

Yeah, adding GetPixelTypeInfo to IPixel would be the safest way so it's not an optional overwrite, we can then encapsulate all pixel format related information in that type.

Because of the overlapping concepts, I didn't see anything against using the same type for this and the stuff returned IImageInfo.PixelTypeInfo, so we can provide a format-agnostic API to observe raw pixelformat information in encoded streams. We just need to make IImageInfo.PixelTypeInfo (or maybe individual PixelTypeInfo properties?) nullable.

[JimBobSquarePants]

Yep, sounds good👌

[antonfirsov]

use the bit depth to determine if the image should be loaded as Rgba64 or Rgba32.

@0xC0000054 what do you do with the image after decoding it? Do you apply built-in processors like Resize, or do you need to access the pixel buffers manually (image[x,y], image.GetPixelRowSpan(y))?

Assuming the first case, if the (non generic) Image.Load would decode the (non-generic) Image into the right pixel format, it would fix your issue without any extra code.

[JimBobSquarePants]

@0xC0000054 V4 will have this information. We'll provide per component bit depth and ordering as well as color type metadata