17.3 - rendering JPEG–HT .JPH image sequences

Support for decoding and encoding JPEG–HT .JPH image sequences.

Just installed 17.3 on an Intel Mac and I'm not seeing how to render .JPH image sequences. Looking forward to giving this a try.

I think it's these settings?

Wow this JPEG-HT is pretty incredible. I just did a couple of tests.

Rendering a 1920x1080 EXR sequence I have on a timeline, 14252 frames, no Color or other effects, reading/writing from/to local NVMe drive:

• To .JPH JPEG-2000 HT, 10-bit, Lossless Compression:
  
  • Average speed: 245 FPS, average file size: 1.80MB
• To .DPX RGB 10-bit:
  
  • Average speed 115 FPS, average file size: 7.91MB

JPH rendered at twice the speed, and produced less than one quarter the file size! That's pretty amazing.

Only problem I have is.. I don't have any other software that can read these files Fusion Studio can't, even via FFMpeg, and that's the software I'd want to use a file sequence to interchange with. Premiere Pro can't either, not that I really care about that.

Oh well, looks to be a pretty amazing codec for those who can use it!

Can jpeg-HT be used as an intermediate codec instead of exr, tiff or dpx?

I think it's these settings?

Nice, thanks for pointing that out to me. I figured it might be under the J2k settings but I didn't scroll far enough down.

Can jpeg-HT be used as an intermediate codec instead of exr, tiff or dpx?

I haven't tested out the Resolve implementation yet, but from skimming the white paper my understanding is that it can store 16 bit integer and half float images. So yes, it could replace EXR (floating point) and DPX (integer) in certain situations. What I'm not clear on yet is if you render an ACES timeline from Resolve that you want to mimic an ACES EXR, if the encoder knows that the image needs to be encoded as half-float vs integer since there doesn't seem to be a way to define that.

DCP-O-Matic should read it: https://dcpomatic.com.

HT is a new block coding algorithm for JPEG2000 and stands for High Throughput. Kakadu (which libraries are used in Resolve) was one of the early developers if I understand it correctly.
In short- for the price of few (around 5) % bigger files you get same quality, but at 5-10x better speed (sort of new version of Cineform).
Support for this format is limited atm. but I'm sure it will spread.

White-papers:
https://www.htj2k.com/wp-content/upload ... -paper.pdf
http://ds.jpeg.org/whitepapers/jpeg-htj ... epaper.pdf

2nd white paper mentions that with common GPUs 8K 120fps encoding is possible in realtime (very difficult for JPEG2000).

HT is a new block coding algorithm for JPEG2000 and stands for High Throughput. Kakadu (which libraries are used in Resolve) was one of the early developers if I understand it correctly.
In short- for the price of few (around 5) % bigger files you get same quality, but at 5-10x better speed (sort of new version of Cineform).
Support for this format is limited atm. but I'm sure it will spread.

White-papers:
https://www.htj2k.com/wp-content/upload ... -paper.pdf
http://ds.jpeg.org/whitepapers/jpeg-htj ... epaper.pdf

2nd white paper mentions that with common GPUs 8K 120fps encoding is possible in realtime (very difficult for JPEG2000).

Right, you may have noticed the white paper mentioned 16 bit half-float precision is supported, and they do a speed test vs various flavors of EXR compression schemes vs uncompressed. so it could be an interesting kind of compressed deliverable of an ACES archival master...although technically it wouldn't conform any more to the ACES standard, but whatever!

It seems the implementation in Resolve currently may just be up to 16-bit integer though. Tbh 12-bit log integer may be of more interest. From what I understand, we don't get any real documentation for these new features added at a fast clip in the rolling updates.

I would prefer this to be wide spread than outdated and simply "to computational" original JPEG2000.
Not sure why companies keep fighting with Jpeg2000 when something "better" can be easily developed today.

Well, more and more keep giving up with Jpeg2000. RED gave it up for the place of 'simpler' DCT based codec. This is what opened them to 8K at 120fps in their new camera. With Jpeg2000 this requires insane processing power. 5% (or even 20%) bigger file size is simply not worth the Jpeg2000 crazy processing requirements.

Haven’t looked at the tech side so wondering why jpeg2000 is so heavy to encode/decode when for example cineform which is also wavelet based is very light and symmetric for encode/decode. As I understand it, the algorithm for cineform is very simple and trivial to parallelize.

I'm don't understand it but it's due to this:
"HT is a new block coding algorithm for JPEG2000 and stands for High Throughput."
Jpeg2000 uses complex block coding where Cineform and HT use simple ones for the price of few % efficiency loss. I think someone has finally realised that it's totally pointless to use such a complex math when way simpler one losses just few % in efficiency. It's about the same as using placebo preset in x264/5 encoders- basically pointless (except for some scientific measures).

I'm confirming that the 16-bit version does clamp linear floating point images. The white paper does say that 16-bit half float is possible, and they do some encode/decode tests vs OpenEXR images, so I think it should be added. This could be a good alternative to OpenEXR DWAA compression, and hopefully Nuke supports it soon as well so that there's a bit of interoperability.

From my very brief tests, the 12-bit lossy compressed version is pretty nice coming in around 1MB/frame for 2K DCI. A good option for log images. I have not figured out the compression settings at all though.

hello
I've recently discovered J2KHT in Resolve
I made some test ans it's clearly faster that J2K-1
J2KHT hasn't J2K-1 quality scalability
Questions :
1 - why isn't used for IMF Disney, IMF Netflix & IMF Sony ?
2 - Why isn't used for 2K DCP (which doesn't need the "scalability") ?

I feel a big technical reason ... but i don't know it

It's new, so this the main reason.
I don't actually know any other tool which supports it expect Resolve.
Old Jpeg2000 decoders won't work.

It's new, so this the main reason.

I agree It's not even in File ➧ e Media management

Old Jpeg2000 decoders won't work.

OK
Many Thanks

JP2K-HT could be a good render cache Codec, no ?

Hmmm... yes, but in the same time nothing that better compared to current choices.
On new Macs you want ProRes as this flies on Apple hardware accelerators.
On Windows it could be a choice, but DNxHR/Cineform is good as well.

Hmmm... yes, but in the same time nothing that better compared to current choices.
On new Macs you want ProRes as this flies on Apple hardware accelerators.
On Windows it could be a choice, but DNxHR/Cineform is good as well.

yes nothing is gonna beat the hardware acceleration

but I don't recall that Apple ProRes or DnxHR or Cineform are/could be 16 bits
I'm aware that BlackMagicDesign's doing a trick with the render cache files that makes them "like" half-float format.

They can do 16-bit only for Alpha channel inclusion.

They can do 16-bit only for Alpha channel inclusion.

Thanks
I knew it.. i was referring to RGB/YUV layers

If you need 16bit then this could be useful.
Do you really need 16bit cache?

If you need 16bit then this could be useful.
Do you really need 16bit cache?

From Fusion to Color

What's the benefit it should give over half-float exr? To even reach parity it should have all the flexibility of exr metadata and channel management first, and it is a stretch for anything with JPEG in its name.

What's the benefit it should give over half-float exr?

Space storage
JP2K-HT has a very attractive Quality/Space storage ratio ... with a very low CPU usage (very Fast) and in 4:4:4 16bits
It cannot compete with hardware acceleration
About lossless compression .... they all end up with almost the same space storage.

What's the difference between JPEG-HT and exr DWA/B compression space wise? Didn't find any direct comparisons for the two.

What's the difference between JPEG-HT and exr DWA/B compression space wise?

I don't know much about exr DWA/B compression. I've just read about it. It seem also great
It could be also great render cache file format
Thanks for pointing me that

It is and I'd suggest using exr-s instead of something that isn't supported anywhere and which most probably lacks most of the exr features There's a reason why exr is so widely used in vfx field, no need to reinvent the wheel.

It is and I'd suggest using exr-s instead of something that isn't supported anywhere and which most probably lacks most of the exr features There's a reason why exr is so widely used in vfx field, no need to reinvent the wheel.

I agree with you

What's the difference between JPEG-HT and exr DWA/B compression space wise? Didn't find any direct comparisons for the two.

HT can be any compression you want. DWA/B are fixed at some ratios. Most interesting difference is in speed. I'm not sure but DWA/B is relatively slow no?

DWAA and DWAB have flexible compression levels too, not fixed. Relatively slow is, well, relative. Relatively to what? Since file sizes are a lot smaller than dpx or lets say zip1 exr, it is purely cpu bound and as far as I can see it is pretty light to encode/decode.

Ok- they will be relatively fast as they are DCT based (I thought they are wavelet).
No idea how it would compare to new HT mode. Efficiency will be most likely on HT side.
HT is starting to spread. Colorfront also added support for it and it may actually replace old Jpeg2000 for IMF deliveries. It makes perfect sense at any place where no hardware decoder is involved.