1

I need to call the following Intel IPP methods on an input image data.

  • ippiColorToGray
  • ippiLUTPalette
  • ippiScale (just for 16 bit images)
  • ippiCopy
  • ippiSet
  • ippiAlphaComp

I was using the 8-bit and 16 bit versions of this methods till now. But now we also allow 12 bit images as input. For ippiLUTPalette, I see that we can pass the bitSize that we are dealing with. But for the other API's we don't have it.

One approach, I was thinking of, was to convert the images that has a bit depth falling between 8 and 16 bit to a 16 bit image and continue working on the result. I believe, ippiScale performs such conversions. But I couldn't find a flavor of it that works on bit depths other than 8, 16 & 32.

Is there a way to perform this convertion?

Or Is it possible to call the before mentioned APIs on images with bit depths other than 8 and 16 bits?

sajas
  • 1,599
  • 1
  • 17
  • 39
  • 1
    It is likely that your 10-bit or 12-bit image is stored using 16 bits per sample. If so, you can just treat it as a 16-bit image, except that the maximum value in it is 1024 or 4092 instead of 65k. – Cris Luengo Mar 09 '18 at 06:25
  • @CrisLuengo Thank you – sajas Mar 09 '18 at 11:08

1 Answers1

3

Datatypes are based on the processor architecture. Usually they are a fraction or multiple of the word length.

Hence with modern CPUs and therefor in modern programming languages there is no 12bit datatype. You have 64, 32, 16, 8 of adressable memory.

But no one stops you from putting a smaller number of bits into a register.

So if you want to store 12bit you usually store them in the lower 12bits of a 16bit type.

Thats's why image processing algorithm usually support 8, 16,... bit. You can use any 16bit algorithm to work on 12bit intensity information as you would on 16bit.

In some cases you may scale the 12bit information to 16bit. But in most cases that is not necessary.

Scaling 12 to 16bit is simple math. 12bit_value / (2^12-1) = 16bit_value / (2^16-1). Of course you may also refer your 12bit value to the maximum value in the image instead of 2^12. Then you would always use the full 16bit.

Piglet
  • 27,501
  • 3
  • 20
  • 43
  • Thanks for your answer. Just one question though, If we end up using the same amount of memory for 12 bit as 16 bit, what is the advantage of going for a 12 bit image? – sajas Mar 09 '18 at 11:11
  • @sajas there is no advantage. It's just a matter of quantization. Most camera's only have a 8, 10 or 12bit ADC. So for 12bit resolution any intensity value will be in the interval [0,4095]. There's no reason why they should scale that to 16bit. – Piglet Mar 09 '18 at 11:27
  • Do any uncompressed storage formats pack the 10 or 12-bit components in groups? e.g. 6 * 12 bits = 72 bits = 9 bytes per 2 pixels (for yuv444 or rgb, no subsampling). I checked FFmpeg sources, and internally the high-depth formats it all seem to pad to a whole number of bytes for every component, though. (https://github.com/FFmpeg/FFmpeg/blob/89216895757c3dad40379eae939419bb2e736d9d/libavutil/pixfmt.h#L148) – Peter Cordes Mar 09 '18 at 11:46
  • @PeterCordes: I'm not an expert on compression, but I imagine it might be easier to exploit the redundancy in images if the bits are not packed. E.g. MPEG encodes shifts of blocks of pixels, which might be hard to do if those pixels are packed. The goal of image compression is to output a bit stream with as high an information content as possible. Thus the output stream will be packed in some way (e.g. Huffman coding), but that output stream no longer is a fixed number of bits per pixel. – Cris Luengo Mar 09 '18 at 14:14
  • @CrisLuengo; I was asking about *uncompressed* formats, i.e. like you might find in video RAM in a high-depth video mode, or an OpenGL texture, where dedicated hardware is going to be processing it. With hardware support, unpacking the components from bitfields for a group of consecutive pixels is not a problem. – Peter Cordes Mar 09 '18 at 23:32
  • @CrisLuengo: But yes, x264 and x265 work with high-depth uncompressed input frames in a 16 bit format when making 9/10/12-bit depth h.264 / h.265 encodes for efficient CPU processing. But note that MPEG-derived codecs compress in the frequency domain (2D DCT, a variant of a fourier transform), the same way JPEG does. Interestingly, upsampling the input bit-depth from 8 to 10 bits [has barely any effect on the visual quality per bitrate](https://video.stackexchange.com/a/21595/9105), and for x264 is actually beneficial (because 10-bit h.264 has more accurate motion vectors than 8-bit h.264). – Peter Cordes Mar 09 '18 at 23:37
  • See https://gist.github.com/l4n9th4n9/4459997 for some points about 10-bit x264 encodes of 8-bit source, and how it reduces banding artifacts. (With x265, there's much less advantage, and maybe none. 8-bit h.265 has higher accuracy motion vectors, and much larger transform blocks (32x32 DCT blocks, instead of only 8x8 for h.264), so it can avoid banding that way.) – Peter Cordes Mar 09 '18 at 23:42