61–70 of 87 posts
Earlier quoted context omitted.
As the thread says - it’s compressed. I’m giving uncompressed sizes as an upper bound.
The GP is pointing out that storing an uncompressed film isn't useful if it can't be played back. Playing back an uncompressed 4K film is nearly 600M B ps. That's a data rate you're not going to get out of any consumer HDDs.
Earlier quoted context omitted.
I think people mis-estimate file sizes these days - two hours of completely uncompressed 4K video is under 5 TB. Fits on a basic consumer external hard drive no problem. Send it by mail. https://toolstud.io/video/filesize.php?width=3840&height=216...
How common is 4K at 24fps though? I'd expect 4K to usually use higher framerates than that.
They tried higher frame rates with for example the Hobbit, remember, and lots of people didn't like it for some silly reason.
There is no such thing as preservation risk for digital formats. This has been studied. Do whatever. The only thing that matters is publishing it in the first place and backing up on hardware that's not at preservation risk. This is great example of fake science (Is it just "science" now?) keep the underclass constantly anxious about things that don't exist so they keep paying academics wages to do nothing but supply…
Earlier quoted context omitted.
Convert them to JPEG XL instead. It seems to be the future widely supported format, and it can loselessly convert back and forth with regular JPEG.
I don't think you can ever convert to a regular JPEG and the outcome will be lossless. Like Webp ,JPEG XL has a lossless setting but it has to remain there.
Earlier quoted context omitted.
This benchmark is showing 4k decoding on commodity hardware from 2018 fast enough for movie theaters. https://www.fastcompression.com/benchmarks/decoder-benchmark... So, presumably they could have swapped to commodity hardware a while ago.
The fastest decoder there uses the GPU, not the CPU. The fastest one that runs on a CPU, Kakadu (proprietary), is far behind.
How does that matter? It was a reply to your incorrect claim:
> it's decoded by (no doubt extremely expensive) hardware
Earlier quoted context omitted.
ImageMagick and GNU parallel happily max-out all cores on my machine and convert a few hundred images per second: find -type f -name '*.jp2' | parallel --xargs --max-args=1 convert {} {.}.jpg
Would be yet another lossy transcode, though.
Earlier quoted context omitted.
I don't think you can ever convert to a regular JPEG and the outcome will be lossless. Like Webp ,JPEG XL has a lossless setting but it has to remain there.
I tried it on my computer. Converting from JPEG to JPEG XL and then back to JPEG gets you a bit-wise identical JPEG file.
Earlier quoted context omitted.
Fun fact, whenever you go to the movies, films (that are projected digitally) are encoding in JPEG2000 (wrapped in a MXF in XYZ Colourspace). We also use it for our 3D renders for archviz, and is supported in our editing applications aswell... lower filesize compared to PNG, and better quality compared to JPG, and also supports alphas.
In other words, motion JPEG2000, and it's decoded by (no doubt extremely expensive) hardware. There's no way a general-purpose CPU can decode in realtime otherwise.
https://www.intopix.com/JPEG2000
Most post-production software that reads/writes DCPs will be using a GPU JPEG2000 encoder & decoder, like this from Comprimato:
Earlier quoted context omitted.
I tried it on my computer. Converting from JPEG to JPEG XL and then back to JPEG gets you a bit-wise identical JPEG file.
I'm guessing the opposite (XL -> JPEG -> XL) does not work, i.e., "losslessly convert back and forth with regular JPEG".
Earlier quoted context omitted.
Fun fact, whenever you go to the movies, films (that are projected digitally) are encoding in JPEG2000 (wrapped in a MXF in XYZ Colourspace). We also use it for our 3D renders for archviz, and is supported in our editing applications aswell... lower filesize compared to PNG, and better quality compared to JPG, and also supports alphas.
JPEG2000 is big in medical imaging as well.
In this case, the jpeg 2000 is probably considered a derivative and thus not a big issue for preservation.