Live data from Hacker News

Is JPEG 2000 a preservation risk? (2013)

blogs.loc.gov

31–40 of 87 posts

Re: Is JPEG 2000 a preservation risk? (2013)

#31
post #30

Earlier quoted context omitted.

Why was it a huge mistake? There are decent libraries that support it. Did it just not work with your cloud setup or OS libraries?

Check the article’s discussion of rendering bugs and implementation incompatibilities.

Sure those were encountered there, but at least in my experience those are easily avoided. I have had to make test suites for this, and in my experience if you use reasonable libraries things work well.

Re: Is JPEG 2000 a preservation risk? (2013)

#32
post #23

Earlier quoted context omitted.

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.

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.

With a Windows Update banner and forced reboot right at the climax of the movie.

Re: Is JPEG 2000 a preservation risk? (2013)

#33
post #5

Earlier quoted context omitted.

Are they not common in pdf documents, for example those distributed by The Internet Archive? I suspect this is why so many of them render so slowly, even on fast systems.

Yes. It's very noticeable when you're reading an ebook with J2K page images, just due to how long it takes each page to render. In contrast, regular JPEG of the same dimensions is practically instantaneous. PDFs are probably where the majority of users will encounter J2K.

Do there currently exist tools for transcoding the images to something which renders faster?

Re: Is JPEG 2000 a preservation risk? (2013)

#34
post #32
post #23

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.

With a Windows Update banner and forced reboot right at the climax of the movie.

Commodity hardware doesn't require Windows...

Though lets be honest, they'd probably use Windows anyways and that probably would happen.

Re: Is JPEG 2000 a preservation risk? (2013)

#35
post #23

Earlier quoted context omitted.

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.

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.

Re: Is JPEG 2000 a preservation risk? (2013)

#36
post #23

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.

CPU or GPU it’s still commodity hardware.

Re: Is JPEG 2000 a preservation risk? (2013)

#37

I think a distinction needs to be made between “risk” and “potential inconvenience”. Given that there are free, open source implementations of the JPEG 2000 decoder, There is no plausible preservation risk. Even if, in 150 years, the contemporary version of ImageMagick has dropped support for JPEG 2000, it would be relatively trivial to spin up an ancient virtual machine and run a 100-year-old version of Linux. Or, y…

Software rots man. It can be really hard to run some open source software from the 80s and 90s. This is actually one of the big arguments for Open Source: Access to the software is way less interesting than the support/community/ecosystem around it; there's no reason not to open source your software and not doing it actually harms the users.

Re: Is JPEG 2000 a preservation risk? (2013)

#38
post #19

Earlier quoted context omitted.

Well, two hard drives in RAID-0 if you want to play it back in real-time without copying it first to faster storage, because a single SATA drive cannot sustain 597.2MB/sec. Unless your definition of "basic consumer external hard drive" is an NVMe SSD over 10Gbps USB 3.2 or better.

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 600MBps. That's a data rate you're not going to get out of any consumer HDDs.

Re: Is JPEG 2000 a preservation risk? (2013)

#39
post #2

Looks like the answer was 'yes', in something of a self-fulfilling prophecy. When was the last time you used a JPEG 2000? https://caniuse.com/jpeg2000 puts browser adoption today at 18% (!).

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 what way is it interesting to note that the format is used by someone, somewhere, for something?

That much is a given, and addresses none of the article's points.

Re: Is JPEG 2000 a preservation risk? (2013)

#40
post #2

Looks like the answer was 'yes', in something of a self-fulfilling prophecy. When was the last time you used a JPEG 2000? https://caniuse.com/jpeg2000 puts browser adoption today at 18% (!).

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.

Sadly, I was going to reply with "daily" because of this
Post reply on HN