Glad I could help. It's good to see uptake of the new lossless feature
in downstream software.
On 1/22/24 1:24 PM, kevle wrote:
Thanks a lot! That is exactly what I needed to know.
The additional context makes all the difference.
>> Since the decompressor automatically handles lossless vs. lossy
mode, it isn't functionally critical for applications to have that
information.
A brief description of the motivation for having lossless vs. lossy
mode information available:
From what I can gather, the DCMTK library bundles an adapted libjpeg
v6b version with Ken's patch applied and some additional fixes.
When it comes to color space conversion, there is a flag that allows
color space conversion only when the file has been stored lossy:
https://github.com/DCMTK/dcmtk/blob/master/dcmjpeg/libsrc/djdijg12.cc#L329
Upon looking into the possibility of replacing the bundled libjpeg
version with libjpeg-turbo, knowing when the code is dealing with
decompressing a lossless image was one of the roadblocks.
Thanks again!
Best regards,
Kevin
On Sunday, January 21, 2024 at 6:21:10 PM UTC+1 DRC wrote:
The lossless JPEG feature was originally implemented by Ken
Murchison as a patch against libjpeg v6b in 1999. (The patch was
never adopted into libjpeg, probably because Tom Lane was already
moving away from the project at that point.) As implemented,
Ken's patch introduced new fields into the public
jpeg_compress_struct/jpeg_decompress_struct structures that
allowed lossless mode to be enabled (compression) and queried
(decompression.) However, that broke backward API/ABI
compatibility, which is a non-starter for libjpeg-turbo. Thus, in
the process of integrating Ken's patch, I heavily restructured it
and moved the new lossless parameters into the private
jpeg_comp_master/jpeg_decomp_master structures. (Refer to
https://github.com/libjpeg-turbo/ijg/commits/6b_lossless to see
how this all played out prior to the feature being merged into
libjpeg-turbo.)
The lack of an intuitive way to query lossless mode in the public
decompressor API was an oversight on my part. However, the good
news is that you can still do it. It's just really subtle and
requires digging through wizard.txt to figure it out. In a
lossless JPEG image, Ss will always be non-zero and Se will always
be 0. That's because Ss in a lossless JPEG image is the predictor
selection value, which must be between 1 and 7 (inclusive), and Se
is specified to be 0. That combination of scan parameters is
illegal for a lossy JPEG image, in which Se must be greater than
or equal to Ss. Thus, if any scan has Ss != 0 and Se == 0, then
the JPEG image is lossless. The compressor takes advantage of
that fact to automatically enable lossless mode if a scan script
specifies a scan with Ss != 0 and Se == 0:
https://github.com/libjpeg-turbo/libjpeg-turbo/blob/335ed793f92370edbb425d56fe9c07aab5a93d9a/jcmaster.c#L184-L193
Thus, lossless mode can implicitly be enabled through a scan
script without explicitly calling jpeg_enable_lossless(), just
like progressive mode can implicitly be enabled through a scan
script without explicitly calling jpeg_simple_progression().
To make this more intuitive, I would probably need to introduce
the get/set API that I implemented for mozjpeg, which extends the
public libjpeg API to allow getting and setting the value of
arbitrary parameters (including those that are stored in the
opaque master structures.) That would not break backward API/ABI
compatibility, but it would break forward API/ABI compatibility
(meaning that applications that took advantage of the new
functions would not work with prior versions of libjpeg-turbo.)
Thus, I would have to be really careful when integrating the
feature, and it would probably have to land in a major new release
rather than a bug-fix release.
Since the decompressor automatically handles lossless vs. lossy
mode, it isn't functionally critical for applications to have that
information. Thus, since there is already a non-intuitive but
still straightforward and reliable way to obtain that information,
my inclination is not to introduce a major new feature solely for
that purpose.
On 1/21/24 6:01 AM, kevle wrote:
Hello everyone,
I have been trying to find out if I can determine whether a jpeg
file is lossless or lossy when decompressing it using the libjpeg
API.
From what I can tell, it might be possible that the internal
state in "master->lossless" is setup after a call to
"jpeg_read_header".
However, I have not seen a way to access that property by using
the public API.
In TurboJPEG API 3, there is "tj3Get" and "TJPARAM_LOSSLESS" that
can probably be used for the same purpose.
The question is, can I also access the "lossless" property using
the public libjpeg API or is there an indirect way of deriving
that information with public API calls?
Best regards,
Kevin
--
You received this message because you are subscribed to the
Google Groups "libjpeg-turbo User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to libjpeg-turbo-u...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/libjpeg-turbo-users/1ddcbe50-7118-4aa6-a6ec-99e99b91627bn%40googlegroups.com
<https://groups.google.com/d/msgid/libjpeg-turbo-users/1ddcbe50-7118-4aa6-a6ec-99e99b91627bn%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "libjpeg-turbo User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to libjpeg-turbo-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/libjpeg-turbo-users/c3778aa4-77c7-4e6b-88bc-46bdeb721ae3n%40googlegroups.com
<https://groups.google.com/d/msgid/libjpeg-turbo-users/c3778aa4-77c7-4e6b-88bc-46bdeb721ae3n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"libjpeg-turbo User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to libjpeg-turbo-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/libjpeg-turbo-users/a5cb8189-3d17-49c6-8618-aac58455a195%40virtualgl.org.
