Results 1 to 12 of 12

Thread: JPEG XL overview available

  1. #1
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    875
    Thanks
    242
    Thanked 324 Times in 197 Posts

    JPEG XL overview available


  2. Thanks:

    SolidComp (17th April 2019)

  3. #2
    Member SolidComp's Avatar
    Join Date
    Jun 2015
    Location
    USA
    Posts
    353
    Thanks
    131
    Thanked 54 Times in 38 Posts
    This is interesting. I'm glad it supports HDR images. It might solve the problems that Netflix outlined here concerning HDR images and graphics for their UI.

  4. #3
    Member SolidComp's Avatar
    Join Date
    Jun 2015
    Location
    USA
    Posts
    353
    Thanks
    131
    Thanked 54 Times in 38 Posts
    Jyrki, what do you think of the 32-bit per channel color support? What would that look like? Is it overkill? Would human eyes appreciate the difference in, say, 12-bit per channel color vs. 8-bit?

    10 and 12 bit seem to be the targets for HDR video (Dolby Vision, HDR10, etc.) 32-bit would be 128 bits per pixel if they also have a 32-bit alpha channel.

  5. #4
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    875
    Thanks
    242
    Thanked 324 Times in 197 Posts
    Quote Originally Posted by SolidComp View Post
    Jyrki, what do you think of the 32-bit per channel color support? What would that look like? Is it overkill?
    8 bits is not quite enough for sdr, and 10 bits is better there. For hdr 15 bits seems to be enough. So, yes, 32 bit internals are an overkill. The choice of internally 32 bits based on availability of simd primitives. 16 bit integers would have made possibly more sense but decoding would have been slower.

  6. #5
    Member SolidComp's Avatar
    Join Date
    Jun 2015
    Location
    USA
    Posts
    353
    Thanks
    131
    Thanked 54 Times in 38 Posts
    Jyrki, are you working on the JPEG XL project? Is there any cross-pollination between JPEG XL and PIK? What will become of PIK?

  7. #6
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    875
    Thanks
    242
    Thanked 324 Times in 197 Posts
    Quote Originally Posted by SolidComp View Post
    Jyrki, are you working on the JPEG XL project? Is there any cross-pollination between JPEG XL and PIK? What will become of PIK?
    Yes, fully working on a pik derivative as one of the codecs in jpeg xl. We are in the phase where we are removing 'unnecessary moving parts' and writing the spec.

  8. #7
    Member SolidComp's Avatar
    Join Date
    Jun 2015
    Location
    USA
    Posts
    353
    Thanks
    131
    Thanked 54 Times in 38 Posts
    Quote Originally Posted by Jyrki Alakuijala View Post
    Yes, fully working on a pik derivative as one of the codecs in jpeg xl. We are in the phase where we are removing 'unnecessary moving parts' and writing the spec.
    Cool, let me know if you need help. I'm good at spec writing, though I've never written a spec for an image format.

  9. #8
    Member
    Join Date
    Aug 2017
    Location
    Romania
    Posts
    4
    Thanks
    0
    Thanked 1 Time in 1 Post
    For what will the PIK based codec will be used in Jpeg XL?

  10. #9
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    875
    Thanks
    242
    Thanked 324 Times in 197 Posts
    Quote Originally Posted by mo0n_sniper View Post
    For what will the PIK based codec will be used in Jpeg XL?
    For general purpose lossy image compression. It is rather close to being a traditional jpeg, just more dense.

  11. #10
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by Jyrki Alakuijala View Post
    8 bits is not quite enough for sdr, and 10 bits is better there. For hdr 15 bits seems to be enough. So, yes, 32 bit internals are an overkill. The choice of internally 32 bits based on availability of simd primitives. 16 bit integers would have made possibly more sense but decoding would have been slower.
    What is certainly necessary to understand is how you define HDR. There are two approaches: The approach taken by MPEG assuming an n-bit integer representation which then undergoes an EOTF to map it to radiance values, and the EOTF is signaled by additional metadata. There is also the approach that was taken by JPEG XT Part 7 (unlike Part 6, which follows the EOTF approach) where you assume that your images are represented in relative or absolute radiance, and the radiance is then the pixel value. This then follows the workflow in computational photography, and the approach OpenEXR uses. In the latter case, you want to have at least 16 bit, which are then however floating point. While 32 bit are probably overshoot, you may want to look into JPEG 2000 part 2 where the number of bits in exponent and mantissa are signaled, and a floating point format is being used. By that I mean that a simple "int only" approach may not be fully sufficient, and 16 bits may not be fully sufficient if you have radiance images.

  12. #11
    Member SolidComp's Avatar
    Join Date
    Jun 2015
    Location
    USA
    Posts
    353
    Thanks
    131
    Thanked 54 Times in 38 Posts
    Quote Originally Posted by thorfdbg View Post
    What is certainly necessary to understand is how you define HDR. There are two approaches: The approach taken by MPEG assuming an n-bit integer representation which then undergoes an EOTF to map it to radiance values, and the EOTF is signaled by additional metadata. There is also the approach that was taken by JPEG XT Part 7 (unlike Part 6, which follows the EOTF approach) where you assume that your images are represented in relative or absolute radiance, and the radiance is then the pixel value. This then follows the workflow in computational photography, and the approach OpenEXR uses. In the latter case, you want to have at least 16 bit, which are then however floating point. While 32 bit are probably overshoot, you may want to look into JPEG 2000 part 2 where the number of bits in exponent and mantissa are signaled, and a floating point format is being used. By that I mean that a simple "int only" approach may not be fully sufficient, and 16 bits may not be fully sufficient if you have radiance images.
    Which MPEG standard are you referring to?

    Also, what approach do they take for HDR video like in HDR10+ and Dolby Vision? Are they mapping to radiance values? HDR10+ uses 10-bit integers, not surprisingly. Dolby Vision is 12-bit, and I think it must be integers not FP (there might also be a 10-bit form of Dolby Vision but I'm not sure).

  13. #12
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    875
    Thanks
    242
    Thanked 324 Times in 197 Posts
    15 bits gives 32768 values. JPEG XL XYB colorspace uses always cubic mapping to get photons from the compressed values. This means dynamic range is 1 : 32768³, i.e., 1 : 35184372088832. While some image formats may give more dynamic range, JPEG XL should be enough for all comfort viewing with about 7 orders of magnitude of headroom.

Similar Threads

  1. JPEG issues a draft call for a JPEG reference software
    By thorfdbg in forum Data Compression
    Replies: 11
    Last Post: 19th April 2017, 16:18
  2. JPEG XT Demo software available on jpeg.org
    By thorfdbg in forum Data Compression
    Replies: 40
    Last Post: 16th September 2015, 15:30
  3. Replies: 9
    Last Post: 11th June 2015, 23:28
  4. Replies: 0
    Last Post: 6th February 2015, 05:57
  5. lzpm overview
    By encode in forum Forum Archive
    Replies: 4
    Last Post: 14th April 2007, 22:30

Posting Permissions

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