Page 1 of 2 12 LastLast
Results 1 to 30 of 41

Thread: JPEG XT Demo software available on jpeg.org

  1. #1
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts

    JPEG XT Demo software available on jpeg.org

    Hi folks,

    sorry for taking so long, but we've finally a demo software for JPEG XT - our new compression standard backwards compatible to JPEG - online at our committee web site at www.jpeg.org. Please get it here:

    http://www.jpeg.org/jpegxt/software.html

    The software comes dual-licensed. There is a GPLv3 version which gives you rights on the sources and IPRs, includes *all* of JPEG (including hierarchical, AC-coding, and lossless, i.e. it is a complete implementation), JPEG LS, but - due to legal constraints - does only include 18477-1/-3/-6/-7 *profile C*/-8. If you need *all* of JPEG XT, please download the ISO version, which includes JPEG XT -3/-6/-7 *all profiles*/-8 but *only* gives you the sources, but *no* IP rights. The ISO version also only includes support for JPEG Huffman/Progressive, but no support for AC coding, hierarchical or lossless, i.e. it is 18477-1, not 10918-1.

    Licences for the ISO version, 18477-7 profiles A and B, must be obtained from the corresponding vendors, i.e. the software comes "as is" without any licenses and any rights on the IPRs. Sorry, this is due to the way how ISO works.

    This version supercedes the version on Github, follows the latest "Committee draft" version of the XT standard so far and includes many bug fixes and improvements. As always, your input is appreciated - thus if you find any bugs, please report them as https://lila-dev.rus.uni-stuttgart.de/bugs. The project name is "libjpeg" (there are other projects on this page).

    Again, we are also inviting anyone to join our mailing list at
    jpeg-extensions@listserv.uni-stuttgart.de

    to subscribe, please send a one or two-paragraph introduction on your background, your motivation for joining and your affiliation, for review of the committee members. Sorry about this formal step, it's what the committee decided, we want to know who's on our list. Subscription requests are usually granted after a one-week review period.

    Thanks and enjoy!

  2. Thanks (4):

    avitar (17th November 2014),load (17th November 2014),Mike (17th November 2014),spark (19th November 2014)

  3. #2
    Member
    Join Date
    Sep 2011
    Location
    uk
    Posts
    238
    Thanks
    188
    Thanked 17 Times in 12 Posts
    Thanks - but baffled by the legalistic stuff. Afraid I'm not familiar with the standards - guess I#'m not the only one on this forum- so which is best version for compressing my .jpgs on win7 - pictures using a 10Mpixel camera eg best compression/fastest. TIA for any help.

    John

  4. #3
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,255
    Thanks
    306
    Thanked 779 Times in 486 Posts
    What is in 18477-7 profiles A and B that we would want?

  5. #4
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by Matt Mahoney View Post
    What is in 18477-7 profiles A and B that we would want?
    18477-7 is all about coding of HDR images, i.e. floating point. Profile A is basically Dolby JPEG-HDR, but with a different syntax. Profile B is Trellis XDepth.

    What is common to all profiles is that they use two JPEG images (LDR,RES) to encode floating point, where LDR is the 8-bit image legacy encoders see, and RES is a residual image. Profile A represents the image as HDR_i = gamma_inv(LDR_i) * exp(RES_0) + LUMA(LDR)*RES_i, profile B basically as HDR_i = gamma_inv(LDR_i) / RES_i and profile C as HDR_I=psi-exp(psi-log(TMO_{-1}(LDR)) + RES_i). Profile A is most stable under local TMOs, the other profiles depend more on the tonemapper that generated the LDR image. Profile B in its simplest variant represents the overexposed image parts in the residual, and the regular image parts in the legacy image. Profile C is an additive residual using a pseudo-logarithmic/exponential map that stems from "casting" IEEE floats to integer (and vice versa). Profile C has the advantage that it is a scalable lossy to lossless compression, i.e. it carries over to 18477-8 and 18477-6, and it doesn't "saturate" for high qualities, i.e. if you continue increasing the quality, you'll end up in "lossless". The other profiles saturate.

    18477-6 is high-precision integer (8-16 bits, IDR), -7 is HDR, -8 is lossless and near-lossless. 18477-9 will add alpha channels. We're currently discussing how to do that - essentially a JPEG image in a side-channel. More on that in the mailing list, see above.

  6. #5
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,255
    Thanks
    306
    Thanked 779 Times in 486 Posts
    Thanks. Are these patented? How are they licensed?

  7. #6
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by Matt Mahoney View Post
    Thanks. Are these patented? How are they licensed?
    Yes, profiles A and B are patented. Profile C is not to my very knowledge - at least I defined the profile, and I didn't patent anything. Given that it's basically the same residual coding idea as in hierarchical JPEG, it's doubful whether any patent applies, but IANAL.

    Profiles A and B are available under RAND conditions. For profile B, a license fee was not excluded (IOW, you likely will have to pay something). At this time, I don't know (yet) which conditions Dolby wanted to enforce on A. It is RAND for sure because that's required by ISO, and - from what I know - it might be even royalty free, but that's only an internal information and I haven't seen that on paper yet.

    The dual licensing is exactly due to that. GPLv3 enforces access to IPRs for its users, and the company that paid for the software wanted to release it only under GPL (Accusoft). Under ISO, however, we cannot enforce vendors to grant access to their IPs for standardization purposes, so the official reference software had to have a statement that IPRs are at the corresponding vendors and the software is only a reference for the implementation. So we came up with the compromize of releasing the JPEG XT reference (without the "obscure" modes of JPEG) under ISO conditions - which is all of JPEG XT but not all of JPEG, and the full software with all of JPEG, but without the patented parts of JPEG XT under GPL.

    In one way, you have now a full demo for JPEG and JPEG-LS (the GPL'd version) and a full reference for JPEG XT (the ISO version). There is a huge non-trivial intersection of the two, and that's JPEG XT part -1 aka JPEG with DCT-Huffman coding, plus parts 6 and 8 complete, plus part 7 profile C.

    Needless to say, this is one of the reasons why it took so long, not really the code itself.

  8. #7
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,255
    Thanks
    306
    Thanked 779 Times in 486 Posts
    Thanks. I wonder why anyone would bother to use profiles A and B when C is better (I think from your description) and not patented. There is also OpenEXR for high dynamic range images. As far as I know, no license is required to use it (but you never know about patents).

    I'm aware that parts of JPEG like arithmetic coding and hierarchical mode with a final lossless step were never implemented (until now) because at the time they were covered by patents. I wouldn't expect those modes to be used in practice even though the patents are now expired (I assume, since the standard was published in 1991), and they are technically superior (better compression). There is very little software that could read them, so people will just stick with baseline and progressive modes which are good enough.

    It just seems to me that parts A and B might be forgotten for the same reason.

  9. #8
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by Matt Mahoney View Post
    Thanks. I wonder why anyone would bother to use profiles A and B when C is better (I think from your description) and not patented. There is also OpenEXR for high dynamic range images. As far as I know, no license is required to use it (but you never know about patents).
    That was pretty much my thinking why I did not want to patent anything of this (besides, it's not really high innovation. I understand that even "almost obvious" stuff had been patented in the past, but I'm not a particular fan of this movement). As far as Profile A is concerned, it might have been that Dolby followed the very same thinking and released it for this reason, but I would need to check. There wasn't an IPR declaration up to the very last moment.

    Quote Originally Posted by Matt Mahoney View Post
    I'm aware that parts of JPEG like arithmetic coding and hierarchical mode with a final lossless step were never implemented (until now) because at the time they were covered by patents. I wouldn't expect those modes to be used in practice even though the patents are now expired (I assume, since the standard was published in 1991), and they are technically superior (better compression). There is very little software that could read them, so people will just stick with baseline and progressive modes which are good enough.
    Believe me, we're fully aware of this problem, and we also understand our tradition: "Baseline should be free". Unfortunately, times are getting considerably hard for following this tradition, and MPEG never followed it in first place - *despite* an ISO recommendation for non-patented solutions.

  10. #9
    Member caveman's Avatar
    Join Date
    Jul 2009
    Location
    Strasbourg, France
    Posts
    190
    Thanks
    8
    Thanked 62 Times in 33 Posts
    Quote Originally Posted by Matt Mahoney View Post
    I'm aware that parts of JPEG like arithmetic coding and hierarchical mode with a final lossless step were never implemented (until now) because at the time they were covered by patents. I wouldn't expect those modes to be used in practice even though the patents are now expired (I assume, since the standard was published in 1991), and they are technically superior (better compression). There is very little software that could read them, so people will just stick with baseline and progressive modes which are good enough.
    IJG libjpeg had support for arithmetic coding since version 7 (and a patch was available for version 6b).
    I’m a bit disappointed by the fact that arithmetic coding is not part of XT, I understand the backward compatible aspect, but are XT files going to share the same file extension and MIME type as legacy JPEG? If yes prepare for great havoc on the web, otherwise XT could have included more of these "obscure" parts since it will be handled as a new image format anyway (sharing a lot of code with legacy JPEG, as a matter of fact). Even hierarchical could have been pushed forward as a single file solution instead of "picture" and to some extend "srcset" for dealing with responsive images http://responsiveimages.org Not sure if webdesigners are going to be thrilled by HDR features, but better compression and multirez images in a single file would probably get some traction.

  11. #10
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by caveman View Post
    IJG libjpeg had support for arithmetic coding since version 7 (and a patch was available for version 6b).
    Yes, but almost nobody uses it. Look, the big goal of XT is really backwards compatibilty to legacy applications - most of which actually run on embedded devices, and most of which actually do not support these modes. It would be a desaster if we would create "just another" standard that breaks applications. In fact, if ultimate compression ratio is your goal and compatibility isn't, you'd already have everything in your hands for that. JPEG 2000 exists for more than 14 years now, and to give you an idea, all the "patent nonense" runs out in about three years giving its age, so you shouldn't really be afraid of anything in this respect.

    Quote Originally Posted by caveman View Post
    I’m a bit disappointed by the fact that arithmetic coding is not part of XT, I understand the backward compatible aspect, but are XT files going to share the same file extension and MIME type as legacy JPEG?
    Yes, likely.

    Quote Originally Posted by caveman View Post
    If yes prepare for great havoc on the web, otherwise XT could have included more of these "obscure" parts since it will be handled as a new image format anyway (sharing a lot of code with legacy JPEG, as a matter of fact).
    No, why? Who is using arithmetic in the web anyhow? Using this obscure mode is asking for trouble in first place, so it's better to avoid. And, to remind you, there's no problem feeding an XT stream into a legacy device. It will just work. It will probably not give you 16bpp precision, or lossless, but it will give you the picture in 8bpp/sample just fine. Thus, we made sure that nothing breaks. The JPEG mime type states that the file follows the specs of ISO/IEC 10918-1, which every XT file will, by definition. In fact, it uses only a subset of the legacy syntax, and the subset that was accepted by the market.

    To be picky, the JPEG that was accepted by the market is actually JFIF (nowadays ISO/IEC 10918-5), not JPEG. JPEG has nothing to say about expansion of subsampling or the conversion from YCbCr to RGB, or the ITU 601 colorspace, quite surprisingly probably. That's all JFIF, not JPEG. The JPEG "file format" is actually SPIFF (ISO/IEC 10918-3) but that's so obscure and came so late that really nobody remembers, and nobody supports that. Thus, what you know as "JPEG" as today is really JPEG XT part 1 and not JPEG part 1, ironically. XT is more compatible to the market than JPEG ever was.
    Quote Originally Posted by caveman View Post
    Even hierarchical could have been pushed forward as a single file solution instead of "picture" and to some extend "srcset" for dealing with responsive images http://responsiveimages.org Not sure if webdesigners are going to be thrilled by HDR features, but better compression and multirez images in a single file would probably get some traction.
    Except that hierarchical is not compatible to baseline - the syntax is different. Thus, if you have an image in 10918-1 that uses hierarchical, the majority (if not all) applications that "claim to support JPEG" will fail on that. They support JFIF or JPEG XT part 1, but not JPEG. (Funny!) This mode is asking for trouble indeed, though it is formally JPEG.

    Anyhow, JPEG is offering a complete(!) JPEG implementation in case people want to try that. Yes, it supports also hierarchical, and arithmetic, and lossless, and JPEG LS, and all combinations thereof. Even a hierarchical with a JPEG-LS scan would be possible, though this is not exposed to the command line.

    You might be delighted that it actually even supports XT with arithmetic coding, though the resulting streams are actually not standard conforming (use the -a command line switch). If you study the standard carefully, you'll notice that there are a couple of placeholders where we can fit that mode in, exactly in the way the software does it today, should AC coding get any market attention. It's an easy exercise to make an AMD to the standard and edit it in, but at this time I wouldn't hold my breath. I don't think it's going to happen.

    As said, if you want better compression or scalability, and compatibility does not play a role, JPEG 2000 is there to give you better performance. (Or HEVC Still Image, if you want even better performance, actually!) If you want compatibility, JPEG XT is there. JPEG XT plus AC coding does not compresses as good as JPEG 2000, and it is not compatible to the majority of implementations (and, to remind you, these are embedded, not software!). So where's the advantage of this mode to begin with? It is a "loose-loose" situation: Lack of performance *and* breaking compatibility is not really a good deal. But hey, you want it, you get an implementation for free. Or rather, FREE.

  12. Thanks (2):

    load (19th November 2014),Matt Mahoney (19th November 2014)

  13. #11
    Member
    Join Date
    May 2015
    Location
    Anywhere
    Posts
    3
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Hi thorfdbg,
    Quote Originally Posted by thorfdbg View Post
    Profile A represents the image as HDR_i = gamma_inv(LDR_i) * exp(RES_0) + LUMA(LDR)*RES_i, profile B basically as HDR_i = gamma_inv(LDR_i) / RES_i and profile C as HDR_I=psi-exp(psi-log(TMO_{-1}(LDR)) + RES_i).
    Is your "TMO_{-1}(LDR)" actually the "inverse TMO function" applied to the LDR !? If so, isn't performance of Profile C very much tailored over the TMO's tested/implemented within the standard ?
    Is it going to fail for any other TMO that might be used in the future ?
    As a side note, Profile A and B might saturate, but indeed they're good for mobile devices, realtime applications and guess: realtime applications on mobile devices! As, again, if that's the inverse TMO, they only require a fraction of the instructions compared to Profile C, looking at the formulas you described.

    On a different matter, do you know what's the algorithm for 18477-6 ? Is it still backward compatible ?

    Thanks!

  14. #12
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by pixpush View Post
    Is your "TMO_{-1}(LDR)" actually the "inverse TMO function" applied to the LDR !?
    "Maybe". In case the original TMO was global, i.e. position-independent, it would be, yes. The "inverse TMO" in the standard is, actually, only a lookup-table of 256 entries - as simple as that.

    Of course, in reality, global TMOs are almost always not as well performing as local TMOs, so it will typically not be the inverse of the forwards TMO. Instead, the encoder tries to find an approximate inverse that approximately minimizes the error, and uses that to generate a prediction image. Only the residual will be encoded.

    Quote Originally Posted by pixpush View Post
    If so, isn't performance of Profile C very much tailored over the TMO's tested/implemented within the standard ?
    Not really. The standard does not define a TMO at all, actually. The encoder architecture - even though not defined by the standard which only specifies the decoder - will take two inputs, the LDR image that legacy applications will reconstruct, and the HDR image. It is the job of the encoder to find a suitable inverse TMO aproximation that minimizes the size of the residual image. In principle, the LDR image could be lena and the HDR image could be barbara. The encoder could encode this combination, though just not very well.

    We made a quite extensive test now (including subjective evaluation) with a set of >100 images, four TMOs including local operators (local Reinhard, local Mantiuk...) and evaluated the result. Interestingly, the result is that profile C seems to perform best, at least in the high-quality regime. It's also explcitly taylored for lossy to lossless coding, i.e. if you set the HDR quality parameter to 100, you'll get lossless.


    Quote Originally Posted by pixpush View Post
    Is it going to fail for any other TMO that might be used in the future ?
    That's highly unlikely. In "worst case", i.e. if the HDR image has no relation to the LDR image, it will be identical to simulcast, i.e. it will transport two images. In reality, the HDR and LDR image are of course correlated (guess what!) and this will be made use of. The decorrelation procedure is extremely primitive, but that's pretty much what we wanted to have, a minimal extension of JPEG.


    Quote Originally Posted by pixpush View Post
    As a side note, Profile A and B might saturate, but indeed they're good for mobile devices, realtime applications and guess: realtime applications on mobile devices! As, again, if that's the inverse TMO, they only require a fraction of the instructions compared to Profile C, looking at the formulas you described.
    Actually, I don't think they are. Profile C is "integer only", so it is very simple to implement. It's two JPEG decoders, one lookup table (inverse TMO) and one addition. Profile A requires an inverse gamma correction, one expontial or lookup table, one multiplication and one addition per pixel. Profile B requires two inverse gammas and one division per pixel, besides A and B require float operations. Thus, I would rather say that "profile C" is currently the simplest to implement.


    Quote Originally Posted by pixpush View Post
    On a different matter, do you know what's the algorithm for 18477-6 ? Is it still backward compatible ?
    Of course, that's the overall design goal of the specs. It is similar to -7 profile C, except that it doesn't use an "half-exponential map" as final output conversion to convert the integer internal representation to float. Actually, this "half-exponential map" does really nothing in a real-world implementation: it just takes a 16-bit integer value and casts this value to IEEE half-float by re-interpreting the bit-pattern, i.e. it is essentially a No-OP. Part 6 and part-7 profile C are identical, except for this output map.

    Despite this "extension of bit depth" in the spatial domain, part 6 and profile C part 7 offer another orthogonal mechanism to extend the sample depth in the DCT domain that is also quite primitive. Think of a standard 8-bit JPEG decoder: it would use 12 bits in the DCT domain to represent the samples. Part 6 and part-7 profile C allow to extend the sample depth in the DCT domain by additional "hidden" scans that encode additional least-significant bits of the DCT coefficients. The LDR signal is in that case reconstructed by the 12 most significant bits of the DCT signal visible to legacy decoders, and an extended intermediate range signal can be obtained by "upshifting" this signal by N bits (N=0...4) and using the additional "hidden" DCT bits to extend the precision in the spatial domain from 8 to 12 bits.

    All the mechanisms can be combined, of course.
    Last edited by thorfdbg; 2nd May 2015 at 15:36.

  15. #13
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Actually, here's the result for part 7 all profiles (A,B and C) in comparison to other standards from the study. Much more needs to be said about this, actually. The attached plot shows the HDR-VDP 2.2 score (Q-value) over the bitrate, for various profiles. We tried of course several methods to evaluate the performance, including PU-quantization followed by SSIM or PSNR, log-PSNR, or MRSE and calibrated all the metrics to the subjective data we obtained. In the end, HDR-VDP2.2 is what worked best (actually, nobody was really surprised about that).

    What is also important to say is that Q values above Q=60 are visually transparent, i.e. the differences you see here are less dramatic in reality than they may appear. I should also say that it wasn't me who made the tests (neither subjective nor objective), but folks at the EPFL (Ebrahimi Touradj's group) and Rafal Mantiuk (thanks Rafal!), so there was certainly no attempt by anyone to "tune" or "drive" the result into a specific direction or to "sell" a specific profile in any particular way, least by me as I was not involved in setting up the tests or defining the test procedure. The result surprised me also a bit given the simplicity of the design.

    There will be a longer article about all this - we do not yet know where precisely, still working on this.
    Attached Files Attached Files

  16. #14
    Member
    Join Date
    May 2015
    Location
    Anywhere
    Posts
    3
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Thumbs up

    Quote Originally Posted by thorfdbg View Post
    Actually, here's the result for part 7 all profiles (A,B and C) in comparison to other standards from the study. Much more needs to be said about this, actually. The attached plot shows the HDR-VDP 2.2 score (Q-value) over the bitrate, for various profiles. We tried of course several methods to evaluate the performance, including PU-quantization followed by SSIM or PSNR, log-PSNR, or MRSE and calibrated all the metrics to the subjective data we obtained. In the end, HDR-VDP2.2 is what worked best (actually, nobody was really surprised about that).
    That is very interesting. Thank you for all the data you shared!
    Actually, I was wondering if you have and could kindly share Matlab code - at least for your algorithms used in part7 Profile C and part6, which is not patented right ? - in order to run some tests.
    If that'd be possible, please PM me, and I'd be glad to share my tests of course.

    As a last "question", what's the intended use of Jpeg XT ? I mean, especially referred to HDR, will there be a "suggested" standard for a single TMO ? How would the encoding encompass any TMO ? (I'm trying to imagine a typical "art" or "photo" workflow... like, have an HDR in Photoshop and Save As JpegXT... who's going to tone map the source HDR, Photoshop or the Jpeg Encoder ? I guess such Photoshop plugin should also be able to provide its own tone-mapped version...etc.).
    Is the purpose broad and general or it directly addresses specific needs ? (digital photography, rather than web usage, scientific purposes etc.)

    Again, thanks a lot!

  17. #15
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by pixpush View Post
    That is very interesting. Thank you for all the data you shared!
    Actually, I was wondering if you have and could kindly share Matlab code - at least for your algorithms used in part7 Profile C and part6, which is not patented right ? - in order to run some tests.
    If that'd be possible, please PM me, and I'd be glad to share my tests of course.
    Actually, I'm not a matlab user, so I cannot give you any matlab type of code. But I'm able to deliver something better, and that is the source code. For that, navigate to www.jpeg.org, click on "JPEG XT", go to "Software", and download there the demo software (incuding sources). It comes in two versions, the GPL'd version which includes all of JPEG (including arithmetic and hierarchical), JPEG LS, part 6, part 7 profile C and part 8 (currently). Or get the ISO version, which includes JPEG XT, part 6,part 7, and part 8 (all complete), but not JPEG LS, not arithmetic, and no hierarchical coding.

    I can also give you a more recent version of the source which *also* includes part 9 (alpha channel coding) plus some bug fixes. Unfortunately, we cannot really publish on www.jpeg.org without a resolution from the committee, so it has to work this way.

    I should also say that for making these tests we used *this* software for profile C, but the implementations of the corresponding proponents for profile A (Dolby) and profile B (Trellis Management). They are possibly, not but not necessarily better than the demo implementation.

    For profile C, the resconstruction algorithm is, however, really trivial: Take a JPEG decoder, expand the subsampling, convert from YCbCr to RGB, call this the LDR signal. For the residual signal, take the residual codestream, reconstruct (usually a 12-bit JPEG, but can also be an 8-bit JPEG), upscale to 16 bit, convert from YCbCr to RGB, call this HDR. Then compute the output as

    output = half-exp(LUT[LDR] + HDR - 2^15)

    where LUT is a 256-entry lookup table. Voila, that's really all. The LUT is recorded in the stream, and if you follow the more constrained definitions for DCT and color transformations from part-8, you're also getting lossy to lossless with a tiny modification with the residual reconstruction.

    As said, it is really fairly trivial.

    Quote Originally Posted by pixpush View Post
    As a last "question", what's the intended use of Jpeg XT ? I mean, especially referred to HDR, will there be a "suggested" standard for a single TMO ? How would the encoding encompass any TMO ? (I'm trying to imagine a typical "art" or "photo" workflow... like, have an HDR in Photoshop and Save As JpegXT... who's going to tone map the source HDR, Photoshop or the Jpeg Encoder ? I guess such Photoshop plugin should also be able to provide its own tone-mapped version...etc.).
    Is the purpose broad and general or it directly addresses specific needs ? (digital photography, rather than web usage, scientific purposes etc.)
    The intended use is that camera vendors use their own TMO (as they do now, in their "JPEG engine" - even though dynamic compression to 8bpp is not part of JPEG, but it's a typical part of the camera logic) to define the LDR part of the image, but store all sufficient data in the extended codestream to allow users to reconstruct a "relative radiance" image in the extension layer. This way, users can still view the photos without much trouble with legacy applications, but are able to "develop" the photos (change the exposure and the tone mapping) with suitable tools, e.g. photoshop. Thus, the TMO is not really used here to generate an "artistic impression" in the camera, we leave that to the end user, but rather to allow camera vendors to store a regular JPEG compatible image, but *also* give the user the full data. Full dynamic range, and/or lossless. Given that the "full data" can also be integer (part 6) it is also a possible replacement for "raw photography", including lossless compression of this data.

    Note again that JPEG XT does not define any TMO at all. It's really agnostic to the TMO used. It's up to the vendors to pick "their" TMO.

  18. #16
    Member
    Join Date
    May 2015
    Location
    Anywhere
    Posts
    3
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Thumbs up

    Quote Originally Posted by thorfdbg View Post
    Actually, I'm not a matlab user, so I cannot give you any matlab type of code. But I'm able to deliver something better, and that is the source code. For that, navigate to www.jpeg.org, click on "JPEG XT", go to "Software", and download there the demo software (incuding sources). It comes in two versions, the GPL'd version which includes all of JPEG (including arithmetic and hierarchical), JPEG LS, part 6, part 7 profile C and part 8 (currently). Or get the ISO version, which includes JPEG XT, part 6,part 7, and part 8 (all complete), but not JPEG LS, not arithmetic, and no hierarchical coding.
    Ok, I had a look at the source code already. I just find Matlab easier when it comes to applying some built-in functions, extract data (like the residuals for instance) and make graphs. It allows to "play" with the code quicker than C/Cpp (to me at least). Maybe I can convert the core encoding/decoding to Matlab code and hand it to you for others who use it.

    Quote Originally Posted by thorfdbg View Post
    For profile C, the resconstruction algorithm is, however, really trivial: Take a JPEG decoder, expand the subsampling, convert from YCbCr to RGB, call this the LDR signal. For the residual signal, take the residual codestream, reconstruct (usually a 12-bit JPEG, but can also be an 8-bit JPEG), upscale to 16 bit, convert from YCbCr to RGB, call this HDR. Then compute the output as

    output = half-exp(LUT[LDR] + HDR - 2^15)

    where LUT is a 256-entry lookup table. Voila, that's really all. The LUT is recorded in the stream, and if you follow the more constrained definitions for DCT and color transformations from part-8, you're also getting lossy to lossless with a tiny modification with the residual reconstruction.
    Absolutely. LUTs are definitely fast. Although, as others teach, what you gain in decoding speed you're probably losing in the encoding part. (?!)
    Many photographers in the few past years were complaining about long saving times on SD Cards... and that was just the time needed to save 10/16 Mbytes on a memory card. (and hence "fast" SD cards saw the light ). If one of the major intended uses is within digital reflex cameras, saving times (and thus pre-processing times) are going to be of some relevance.
    I'm curious to see benchmarks from camera makers, when they'll begin implementing it. Actually... there should be no big surprise, given the "monster-hardware" we have today even on embedded devices!

    Quote Originally Posted by thorfdbg View Post
    The intended use is that camera vendors use their own TMO (as they do now, in their "JPEG engine" - even though dynamic compression to 8bpp is not part of JPEG, but it's a typical part of the camera logic) to define the LDR part of the image, but store all sufficient data in the extended codestream to allow users to reconstruct a "relative radiance" image in the extension layer. This way, users can still view the photos without much trouble with legacy applications, but are able to "develop" the photos (change the exposure and the tone mapping) with suitable tools, e.g. photoshop. Thus, the TMO is not really used here to generate an "artistic impression" in the camera, we leave that to the end user, but rather to allow camera vendors to store a regular JPEG compatible image, but *also* give the user the full data. Full dynamic range, and/or lossless. Given that the "full data" can also be integer (part 6) it is also a possible replacement for "raw photography", including lossless compression of this data.

    Note again that JPEG XT does not define any TMO at all. It's really agnostic to the TMO used. It's up to the vendors to pick "their" TMO.
    Uhmm. Raw photography also gives you the chance to - based on the software used - change the demosaicing algorithm... which I guess you'd lose even with lossless JpegXT. Unless you convert it back to a mosaic/bayer pattern - or if camera makers will drop sensor color patterns altogether! (which is just about time... still robbing users with 1/3rd of the pixels in the sensor...!! :O )
    So current raw files - although uncompressed - benefit from a "natural" 3:1 compression due to being essentially a grayscale signal. Plus, some of them apply generic lossless compression (zip, LZW, or similar). Which is "difficult" to beat with 3 lossless components. Unless you mean "quasi-lossless" referred to JpegXT... then you might actually win.

  19. #17
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by pixpush View Post
    Ok, I had a look at the source code already. I just find Matlab easier when it comes to applying some built-in functions, extract data (like the residuals for instance) and make graphs. It allows to "play" with the code quicker than C/Cpp (to me at least). Maybe I can convert the core encoding/decoding to Matlab code and hand it to you for others who use it.
    The "merging and splitting" logic is in colortrafo/ycbcrtrafo.cpp, and the logic that controls the data flow in control/blockbitmaprequester.cpp. Everything else is just.... all the logic around it, and the well-known jpeg algorithm(s).

    Quote Originally Posted by pixpush View Post
    Uhmm. Raw photography also gives you the chance to - based on the software used - change the demosaicing algorithm... which I guess you'd lose even with lossless JpegXT. Unless you convert it back to a mosaic/bayer pattern - or if camera makers will drop sensor color patterns altogether! (which is just about time... still robbing users with 1/3rd of the pixels in the sensor...!! :O )
    True enough. Unfortunately, getting some hard facts from camera vendors about their sensors, sensor organization or demosaiking algorithms is a rather hopeless attempt. Thus, whatever you specify here as data organization is likely not sufficient to describe the models on the market, leave alone the algorithms or sensor profiles. Thus, the "only" feature XT exposes to the consumer is a linearized, demosaiced sensor output, hopefully abstracting enough from the physics of the sensor.

    If you want an "abstract" representation of RAW files, Adobe DNG is probably your best bet. Well, of some sort - it is not widely enough supported, both in software, and from vendors, to have attracted a large enough market share.


    Quote Originally Posted by pixpush View Post
    So current raw files - although uncompressed - benefit from a "natural" 3:1 compression due to being essentially a grayscale signal. Plus, some of them apply generic lossless compression (zip, LZW, or similar). Which is "difficult" to beat with 3 lossless components. Unless you mean "quasi-lossless" referred to JpegXT... then you might actually win.
    Well, Part 8 is "really lossless". Part 7 is "visually lossless", at least if you trust our subjective tests and the HDR VDP quality index. Of course, there might be still extreme cases we couldn't capture, and where you want to undercompress a lot. The "LZW" compression of image data (as used by some vendors, as you say completely correctly), is from an information-theoretic sense a pretty bad attempt to compress sensor data. LZW is a good algorithm for language/text compression, but for noisy sensor data, it is really the wrong model, and too complex for the 2:1 compression it gains (so, all factors in, you're probably at 1:6). Still, it's used (even in PiNG) because its proponents do not know any better...

  20. #18
    Member
    Join Date
    Jun 2015
    Location
    Rome
    Posts
    12
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Profile B

    Quote Originally Posted by thorfdbg View Post
    18477-7 is all about coding of HDR images, i.e. floating point. Profile A is basically Dolby JPEG-HDR, but with a different syntax. Profile B is Trellis XDepth.
    Hi Thomas,
    I'm Emanuele Salvucci and I wrote the patents for Trellis.
    I'm very glad to see some of the methods I described for HDR compression are evaluated for JpegXT.

    I don't know whether this could help with JpegXT or not, I don't know anything about the standardization process, but since the methods I described in those patents are quite old now (2006/2007), I'm thinking about disclosing my whole personal research I conducted till now, none of which is patented, in a scientific publication, for public use.
    My personal work on HDR includes novel HDR encoding methods (both backward and not backward-compatible), alternative methods to the ones I already disclosed and some attempts to novel tone mapping algorithms.

    So, I'd like to ask you if you could point me to the right scientific "journal" (?!) for being considered for such a publication and - in case - if I could possibly get your help/suggestions while drafting and preparing the document - as I'm no scientist, I have no academic title and I never "published" before. (despite having worked as a contract professor for a University in Rome )


    Thanks for any help!


    Best regards,
    Emanuele.

  21. #19
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by erpy View Post
    I don't know whether this could help with JpegXT or not, I don't know anything about the standardization process, but since the methods I described in those patents are quite old now (2006/2007), I'm thinking about disclosing my whole personal research I conducted till now, none of which is patented, in a scientific publication, for public use.
    First, a patent does not limit the ability to standardize a method, many methods are patented, you just need to mention them. Whether using such patents require payment to make them usable in applications is something completely outside of the ISO standardization process, the only thing we require is that you report your patents. I.e. you cannot come to ISO, have your methods standardized and later on collect money for a patent you have not reported to ISO. If you remember, a certain company tried this with the JPEG 2D-Huffman code and was then defeated by HP and others.
    Quote Originally Posted by erpy View Post
    My personal work on HDR includes novel HDR encoding methods (both backward and not backward-compatible), alternative methods to the ones I already disclosed and some attempts to novel tone mapping algorithms. So, I'd like to ask you if you could point me to the right scientific "journal" (?!) for being considered for such a publication and - in case - if I could possibly get your help/suggestions while drafting and preparing the document - as I'm no scientist, I have no academic title and I never "published" before. (despite having worked as a contract professor for a University in Rome )
    I would suggest publishing at a conference first, see what the reaction on the paper is, then improve and extend it to publish it in a Journal. Various conferences come to my mind. A good one would be the DCC (Data Compression Conference), always in Snowbird, UT, USA (and will be there, too.), next spring. There is the PCS (Picture Coding Symposium), which is specialized to images and video. This will happen again in 18 months or so, I do not yet know where. ICIP is a really big one (International Congress on Image Processing), usually in September/October. Too late for this year, in time for next year. Then there is the SPIE, in San Diego, August. There is the Eurasip conference, a mostly European conference on signal processing... Publishing on the ACM conferences is harder, and it is not exactly on topic. As far as Journals are concerned, there is TIP (Transactions on Image Processing), but it is pretty hard to place a paper there. There is also Elsevier, Image Communication.

  22. #20
    Member
    Join Date
    Jun 2015
    Location
    Rome
    Posts
    12
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by thorfdbg View Post
    First, a patent does not limit the ability to standardize a method, many methods are patented, you just need to mention them. Whether using such patents require payment to make them usable in applications is something completely outside of the ISO standardization process, the only thing we require is that you report your patents. I.e. you cannot come to ISO, have your methods standardized and later on collect money for a patent you have not reported to ISO. If you remember, a certain company tried this with the JPEG 2D-Huffman code and was then defeated by HP and others.
    I see. Although I didn't mean to do that in any way.
    In fact I would like to make a scientific publication of what's not patented because I intend not to patent such matters in the first place.
    Initially I was thinking about releasing an informal "compendium" under Creative Commons Attribution license - which remains an option, if publishing in a scientific conference is too hard or if I don't find any scientist to work with.
    That's why I said it might be useful for XT... it would be totally free info, and anyone would do anything they like with it, if they find it useful.


    Quote Originally Posted by thorfdbg View Post
    I would suggest publishing at a conference first, see what the reaction on the paper is, then improve and extend it to publish it in a Journal. Various conferences come to my mind. A good one would be the DCC (Data Compression Conference), always in Snowbird, UT, USA (and will be there, too.), next spring. There is the PCS (Picture Coding Symposium), which is specialized to images and video. This will happen again in 18 months or so, I do not yet know where. ICIP is a really big one (International Congress on Image Processing), usually in September/October. Too late for this year, in time for next year. Then there is the SPIE, in San Diego, August. There is the Eurasip conference, a mostly European conference on signal processing... Publishing on the ACM conferences is harder, and it is not exactly on topic. As far as Journals are concerned, there is TIP (Transactions on Image Processing), but it is pretty hard to place a paper there. There is also Elsevier, Image Communication.
    Excellent tips, thanks a lot!
    Although I don't ski since ages, Snowbird looks like a nice place, especially if the room has a mountain view.
    And if the paper is accepted at DCC, I guess it cannot be presented at another one, afterwards. (?!) (i.e. do conferences require exclusivity ?)

  23. #21
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by erpy View Post
    I see. Although I didn't mean to do that in any way.
    In fact I would like to make a scientific publication of what's not patented because I intend not to patent such matters in the first place.
    Initially I was thinking about releasing an informal "compendium" under Creative Commons Attribution license - which remains an option, if publishing in a scientific conference is too hard or if I don't find any scientist to work with.
    That's why I said it might be useful for XT... it would be totally free info, and anyone would do anything they like with it, if they find it useful.
    Well, if it fits into our current "generic decoder design" it is surely useful. It is, however, a bit late to consider a new design at this point, so we're likely not extending the standard decoder at this point. It's a bit too late in the process.

    Quote Originally Posted by erpy View Post
    Excellent tips, thanks a lot!
    Although I don't ski since ages, Snowbird looks like a nice place, especially if the room has a mountain view.
    And if the paper is accepted at DCC, I guess it cannot be presented at another one, afterwards. (?!) (i.e. do conferences require exclusivity ?)
    It depends. DCC has two forms of publications: Full papers and posters. Posters only get one page in the proceedings, but the advantage is that you can get for a publication elsewhere. Also, if you extend the work, you can surely make it a journal after having a conference paper. It just needs to be extended and include more material.

  24. #22
    Member
    Join Date
    Jun 2015
    Location
    Rome
    Posts
    12
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by thorfdbg View Post
    Well, if it fits into our current "generic decoder design" it is surely useful. It is, however, a bit late to consider a new design at this point, so we're likely not extending the standard decoder at this point. It's a bit too late in the process.
    Sure, I understand. You need to "close" the standard at some point.

    Quote Originally Posted by thorfdbg View Post
    It depends. DCC has two forms of publications: Full papers and posters. Posters only get one page in the proceedings, but the advantage is that you can get for a publication elsewhere. Also, if you extend the work, you can surely make it a journal after having a conference paper. It just needs to be extended and include more material.
    Very last question. Do I need to physically be there even to present a poster ?
    I was at Siggraph in Boston, in 2006, and I remember poster authors were there to personally attend their assigned "poster location". (...and I remember testing my first HDR video decoder on Brightside's HDR monitor and having a sandwich with Greg Ward at lunch ... quality time! )

  25. #23
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by erpy View Post
    Very last question. Do I need to physically be there even to present a poster ?
    Yes, definitely. If you do not come, your poster and your publication will be removed. Or you find a co-author who goes to DCC and presents the poster for you.
    Quote Originally Posted by erpy View Post
    I was at Siggraph in Boston, in 2006, and I remember poster authors were there to personally attend their assigned "poster location". (...and I remember testing my first HDR video decoder on Brightside's HDR monitor and having a sandwich with Greg Ward at lunch ... quality time! )
    Yes, I know Greg, or rather, we met at Sunnyvale probably two years ago, trying to advance the standard. He was kind enough to present me a copy of his book as a gift. (-:

  26. #24
    Member SolidComp's Avatar
    Join Date
    Jun 2015
    Location
    USA
    Posts
    239
    Thanks
    95
    Thanked 47 Times in 31 Posts
    Interesting. How would this compare to JPEG-XR? That's the only other standardized format I know of to support HDR. Microsoft seemed to abandon the format years ago, showing no energy, providing no tools, but I saw some signs of life from Microsoft Research here: https://hdview.wordpress.com/2013/05/30/jpegxr-updates/

    Also, how would you compare XT to Bellard's BPG format? (http://bellard.org/bpg/)

  27. #25
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by SolidComp View Post
    Interesting. How would this compare to JPEG-XR?
    Actually, you forget JPEG 2000, which also has a HDR mode. It's not so far from JPEG 2000 for lower bitrates. JPEG XR is somewhere between the two. For higher bitrates, JPEG XT looses gain basically because it is backwards compatible, i.e. it always carries a legacy image around. JPEG 2000 and JPEG XR are not, so they don't have this additonal payload to carry.

    Quote Originally Posted by SolidComp View Post
    That's the only other standardized format I know of to support HDR. Microsoft seemed to abandon the format years ago, showing no energy, providing no tools, but I saw some signs of life from Microsoft Research here: https://hdview.wordpress.com/2013/05/30/jpegxr-updates/
    I have really not seen much use of JPEG XR in the wild, though MS claims that they are using something comparable internally for screen content coding and their VNC, i.e. the latest versions of RDP.


    Quote Originally Posted by SolidComp View Post
    Also, how would you compare XT to Bellard's BPG format? (http://bellard.org/bpg/)
    That's essentially HEVC I-frame. Look, JPEG XT is still JPEG, the same old stuff from years ago. HEVC is quite a bit ahead of JPEG 2000, leave alone JPEG.
    Click image for larger version. 

Name:	plots.png 
Views:	347 
Size:	42.3 KB 
ID:	3724
    That, however, does not mean that there is no room for improvement. The above shows PSNR curves (not necessarily "quality") for the "bike" image, for JPEG 2000, JPEG XR, and what is here in red is "JPEG XT part 1" aka "traditional old JPEG as you know it". The two curves in between are *also* traditional old JPEG as you know it, but with a couple of tricks played. That is, while not as good as JPEG XR or JPEG 2000, there is quite some improvement.

    Note, however, that I here optimized JPEG towards ideal PSNR! That is *not* visual quality. If you want to optimize to visual quality, there are again other tricks.

    BTW, the turquoise curve is (almost) mozjpeg, the green curve is something that is a lot simpler than that.

  28. #26
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Click image for larger version. 

Name:	c1.jpg 
Views:	228 
Size:	44.7 KB 
ID:	3725Click image for larger version. 

Name:	c2.jpg 
Views:	226 
Size:	44.4 KB 
ID:	3726
    Here is, for your convenience, another example, just another technology to improve JPEG. This time, it is encoder-side de-ringing. It's all standard JPEG (just download the files, I uploaded them as they came out of my encoder). Both are the same size, actually the better looking one is even slightly smaller. Here on this particular compound image, it's 1dB gain due to suppression of the ringing artifacts.

  29. #27
    Member SolidComp's Avatar
    Join Date
    Jun 2015
    Location
    USA
    Posts
    239
    Thanks
    95
    Thanked 47 Times in 31 Posts
    Interesting. I've only heard of deringing for video. I can see the smudges around the text – looks like an off-white highlighter – which is removed by the deringing.

  30. #28
    Member
    Join Date
    Jun 2015
    Location
    Rome
    Posts
    12
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Hi Thomas,
    I'm having a look at the latest source code posted on Jpeg.org.
    While I still need to go through all of it, I noticed you use the same "split quality" function of the other profiles for Profile B as well.
    I guess this works against quality measurements for Profile B in many test images and for many input quality parameters.

    As you rightfully noted within the code, Profile B implements an "auto exposure" function in order to keep an average value of 0.5 for L in the LDR domain of the image. (i.e. the achieved result is to have an average luminance for all the pixels in the LDR domain == 0.5)
    Since this is done for every input HDR image, you can expect the residual image of Profile B to pretty much always contain wide areas of "white" pixels (RGB == 255), that are "naturally" handled very well in terms of compression by the entropy coding stage in standard Jpeg-1.
    Thus quality values for the residual image can usually be kept between 90 and 95 without significant variations in both quality and bpp compared to lower quality values. (excluding extreme values like Q < 50 and Q > 95 where visual quality is degraded - for little gain in bpp - and bpp are high - with little gain in visual quality - respectively)
    The LDR quality parameter instead should be regarded as the regular quality parameter for an LDR Jpeg image.

    So, all in all, quality parameters for the LDR and RES image of Profile B are quite distinct... one does not "subtract" from the other and viceversa, as suggested in the "SplitQualityB" function.
    Generally I never had to go below 70/80 for the RES image in order to achieve low bpp.

    Also, I hope I gave some more insights as to what's achieved by the "auto exposure" function and why there's an "apparently random" 0.5 in it...

    There's probably more to be said, also wrt the gamma selection function...but I still need to have a proper look.

    Please let me know your thoughts.


    EDIT: this is probably also the reason why most papers reporting quality measurements for JPEG XT Profile B are quite different... and why you have "spiky" graphs for certain values of Q on some test images. That might well be due to the automatic trading between LDR and RES quality performed by the split quality function.
    Last edited by erpy; 25th August 2015 at 02:39.

  31. #29
    Member
    Join Date
    Jun 2015
    Location
    Rome
    Posts
    12
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Further reading the code for Profile B, I noticed the part with the 0.5 "constant" I was referring to in the previous post, isn't the auto-exposure function - which it looks like it's parametrized now using the "efac" variable (?!) - but it's rather the "auto-gamma" function.
    Basically that imposes the min_value to be == 0.5, when the computed "gamma_out" is finally applied to the RES image. This is actually necessary in order to avoid excessive compression of meaningful HDR data, since Jpeg is "aggressive" towards low luminance values.
    That doesn't mean though that "0.5" is optimal. It works fine in many cases as far as I can recall, but I never tested it for being a "sweet spot".
    In fact, it might be cutting some precision...not using the full LDR range for the RES encoding.

  32. #30
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by erpy View Post
    Since this is done for every input HDR image, you can expect the residual image of Profile B to pretty much always contain wide areas of "white" pixels (RGB == 255), that are "naturally" handled very well in terms of compression by the entropy coding stage in standard Jpeg-1.
    There is actually nothing special about the value 255 in regular JPEG, so I wonder what you want to say here.

    Quote Originally Posted by erpy View Post
    Thus quality values for the residual image can usually be kept between 90 and 95 without significant variations in both quality and bpp compared to lower quality values. (excluding extreme values like Q < 50 and Q > 95 where visual quality is degraded - for little gain in bpp - and bpp are high - with little gain in visual quality - respectively)
    The LDR quality parameter instead should be regarded as the regular quality parameter for an LDR Jpeg image.
    That, I would say, rather depends on the histogram of the image. The auto exposure tries to split the histogram into two parts where the split point is the average luminance. Luminances above the average go into the HDR part, luminances below into the LDR part.


    Quote Originally Posted by erpy View Post
    So, all in all, quality parameters for the LDR and RES image of Profile B are quite distinct... one does not "subtract" from the other and viceversa, as suggested in the "SplitQualityB" function.
    Generally I never had to go below 70/80 for the RES image in order to achieve low bpp.
    The SplitQuality function is just a very basic "rate allocation" and tries to adjust the rate distribution approximately even between the two images. There is certainly no simple additive split between LDR and HDR and it is all picture dependent, but given that the auto exposure approximately splits the luminance region into two, it does not seem to be completely unrealistic to assume that each sub-image gets approximately half of the pixels, and hence approximately half of the rate. Of course, this really depends on the histogram, and thus on the nature of the image.



    Quote Originally Posted by erpy View Post
    Also, I hope I gave some more insights as to what's achieved by the "auto exposure" function and why there's an "apparently random" 0.5 in it...
    There is really nothing fancy about it, just read FindEncodingParametersB in cmd/encodeb.cpp. As said, the auto exposure is just a ratio that defines the histogram split.


    Quote Originally Posted by erpy View Post
    EDIT: this is probably also the reason why most papers reporting quality measurements for JPEG XT Profile B are quite different... and why you have "spiky" graphs for certain values of Q on some test images. That might well be due to the automatic trading between LDR and RES quality performed by the split quality function.
    Actually, no. We haven't been using the SplitQuality function for our measurements. Those curves come from a "manual" rate allocation in the (q,Q) domain, i.e. the whole two-dimensional parameter set of HDR and LDR quality is scanned, and the best possible combinations have been selected. The purpose of these studies are not to evaluate the quality of the rate allocation (or histogram split) but rather to estimate the quality of the overall compression performance. For subjective studies, we just used a simple q=Q sampling to get some sampling points which then have been used to calibrate the objective metric (HDRVDP 2.2, amongst others).

Page 1 of 2 12 LastLast

Similar Threads

  1. Replies: 9
    Last Post: 12th June 2015, 00:28
  2. JPEG Metadata
    By lorents17 in forum Data Compression
    Replies: 13
    Last Post: 27th April 2014, 22:29
  3. JPEG Huffman Coding
    By lorents17 in forum Data Compression
    Replies: 26
    Last Post: 16th December 2013, 00:51
  4. list of different jpeg encoders?
    By Mangix in forum Data Compression
    Replies: 4
    Last Post: 21st October 2013, 17:11
  5. Quo Vadis JPEG - an update
    By thorfdbg in forum Data Compression
    Replies: 8
    Last Post: 31st July 2012, 18:35

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •