Current version 1.2.0 does support only 8 bit and 32 bit jpeg images,,, can you kindly add support for 16 bit, Short Gray Scale is widely used in medical Images (DICOM)...
To be clear, libjpeg-turbo only really supports 8-bit JPEG images. When you say "32-bit", you're referring to the input or output RGB colorspace, which still has only 8 bits per component. When decoding a grayscale JPEG to a 32-bit colorspace, libjpeg-turbo simply duplicates the luminance component into the red, green, and blue channels. Similarly, when encoding a grayscale JPEG from a 32-bit colorspace, libjpeg-turbo computes the 8-bit luminance from the red, green, and blue and throws out the chrominance.
Since the JPEG standard cannot accommodate 16 bits per component, short grayscale input/output has to be stored as a 12-bit JPEG, which causes additional data loss, over and above the regular quantization loss that occurs as a matter of course when encoding an image using the JPEG format. libjpeg can't support 8-bit and 12-bit components simultaneously, because the bits per component is hard-coded. Further, libjpeg-turbo offers no performance advantages over libjpeg when handling 12-bit JPEG images. Thus, we've never bothered to make it build properly when BITS_IN_SAMPLE=12.
It would be possible to fix the build issues and add necessary unit tests for 12-bit encoding/decoding, but the resulting build of libjpeg-turbo would have absolutely no advantages relative to libjpeg. Specifically, it would perform the same, and it would not have the higher-level TurboJPEG API (that API assumes 8-bit in too many places to make it feasible to develop a 12-bit version of it.) So, traditionally, my opinion on it has been "why not just use libjpeg for 12-bit?" If someone stepped forward to specifically fund 12-bit support in libjpeg-turbo, then I'm happy to fix the build, add a configure/CMake switch for it, add regression tests, etc., but it won't happen without specific project funding.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Full support for 12-bit JPEG has been checked into trunk. You can enable it by passing --with-12bit to configure (Unix) or -DWITH_12BIT to cmake (Windows.) Note that enabling 12-bit support disables a lot of things:
-- Arithmetic coding is disabled (12-bit support requires multi-pass entropy encoding, which is not compatible with arithmetic coding)
-- The SIMD extensions are disabled (our SIMD code assumes 8-bit components)
-- The TurboJPEG API wrappers are disabled (TurboJPEG assumes 8-bit components)
-- BMP and TGA support in cjpeg and djpeg are disabled (those file formats assume 8-bit components)
The performance of the library in this configuration is identical to libjpeg v6b, if the latter was built with BITS_IN_JSAMPLE=12. However, the libjpeg-turbo version still has the libjpeg-turbo colorspace extensions and support for additional decompression scaling factors. Although 12-bit support still requires a separate build, since it has been made into a configurable option, it is now possible to build both an 8-bit and a 12-bit version within the same source tree without modifying the source.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To be clear, libjpeg-turbo only really supports 8-bit JPEG images. When you say "32-bit", you're referring to the input or output RGB colorspace, which still has only 8 bits per component. When decoding a grayscale JPEG to a 32-bit colorspace, libjpeg-turbo simply duplicates the luminance component into the red, green, and blue channels. Similarly, when encoding a grayscale JPEG from a 32-bit colorspace, libjpeg-turbo computes the 8-bit luminance from the red, green, and blue and throws out the chrominance.
Since the JPEG standard cannot accommodate 16 bits per component, short grayscale input/output has to be stored as a 12-bit JPEG, which causes additional data loss, over and above the regular quantization loss that occurs as a matter of course when encoding an image using the JPEG format. libjpeg can't support 8-bit and 12-bit components simultaneously, because the bits per component is hard-coded. Further, libjpeg-turbo offers no performance advantages over libjpeg when handling 12-bit JPEG images. Thus, we've never bothered to make it build properly when BITS_IN_SAMPLE=12.
It would be possible to fix the build issues and add necessary unit tests for 12-bit encoding/decoding, but the resulting build of libjpeg-turbo would have absolutely no advantages relative to libjpeg. Specifically, it would perform the same, and it would not have the higher-level TurboJPEG API (that API assumes 8-bit in too many places to make it feasible to develop a 12-bit version of it.) So, traditionally, my opinion on it has been "why not just use libjpeg for 12-bit?" If someone stepped forward to specifically fund 12-bit support in libjpeg-turbo, then I'm happy to fix the build, add a configure/CMake switch for it, add regression tests, etc., but it won't happen without specific project funding.
Full support for 12-bit JPEG has been checked into trunk. You can enable it by passing --with-12bit to configure (Unix) or -DWITH_12BIT to cmake (Windows.) Note that enabling 12-bit support disables a lot of things:
-- Arithmetic coding is disabled (12-bit support requires multi-pass entropy encoding, which is not compatible with arithmetic coding)
-- The SIMD extensions are disabled (our SIMD code assumes 8-bit components)
-- The TurboJPEG API wrappers are disabled (TurboJPEG assumes 8-bit components)
-- BMP and TGA support in cjpeg and djpeg are disabled (those file formats assume 8-bit components)
The performance of the library in this configuration is identical to libjpeg v6b, if the latter was built with BITS_IN_JSAMPLE=12. However, the libjpeg-turbo version still has the libjpeg-turbo colorspace extensions and support for additional decompression scaling factors. Although 12-bit support still requires a separate build, since it has been made into a configurable option, it is now possible to build both an 8-bit and a 12-bit version within the same source tree without modifying the source.