Is JPEG 2000 a preservation risk? (2013) • Hacker News Board

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

#71

Post by iggldiggl » Mon, Jul 18, 2022, 10:26 AM UTC

lioeters wrote: post #67

pabs3 wrote: post #64

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".

I think the issue at hand is that behind the scenes, JPEG XL the image format actually combines three different kinds of image compression algorithms:

1. native JPEG XL lossy compression

2. JPEG lossy compression, but using a more space-efficient storage format than classic JPEG

3. lossless compression

The lossless conversion between JPEG XL and JPEG only works with 2).

Normally you'd only use 2) for existing JPEG images in order to avoid a lossy re-compression, and use 1) for any freshly-created images because native JPEG XL compression will compress the image data even more efficiently than the JPEG compatibility-mode, though if you've got strong interoperability constraints with clients requiring JPEG data you might possibly want to store even newly created images using sub-format 2) in order to get the ability to losslessly convert back and forth between JPEG XL and JPEG.

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

#72

Post by alophawen » Mon, Jul 18, 2022, 10:34 AM UTC

tgv wrote: post #51

simondotau wrote: post #49

Earlier quoted context omitted.

Actually, it seems to me VMs are an ideal way to preserve things like that. Perhaps it should be standard procedure for the archivists of such big films to build and preserve a fully functioning, self-sufficient rendering environment in the form of a virtual machine.

Until we switch to another architecture. It's pretty likely the x86 architecture will be gone in a few decades. Rebuilding VM software to run on new hardware is probably harder than fixing bugs in a JPEG decoder.

Dude, that's why we use Virtual Machines. We will run them thru QEMU or another multi-architecture solution.

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

#73

Post by alophawen » Mon, Jul 18, 2022, 10:37 AM UTC

melissalobos wrote: post #31

simonh wrote: post #30

Earlier quoted context omitted.

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.

Are you suggesting the parent sets up test suites for a cloud solution and call it a day?

How would that guarantee safe storage, given the previous discussion of all the broken implementations.

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

#74

Post by notpushkin » Mon, Jul 18, 2022, 10:49 AM UTC

Shared404 wrote: post #34

cm2187 wrote: post #32

Earlier quoted context omitted.

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.

A couple months ago, I've been to a 2020 anime feature film in a cinema here in Estonia. To my amusement, after the credits I was greeted with the VLC interface for a brief moment (though they've turned off the projector very quickly after that).

Edit: obviously, that's not how most movies are shown here :D

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

#75

Post by milderworkacc » Mon, Jul 18, 2022, 10:55 AM UTC

cm2187 wrote: post #32

Retric wrote: 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.

It’s almost worse than that - the common commercial playback servers I’m familiar with run Linux 2.6.x and fail in all kinds of weird and wonderful ways!

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

#76

Post by milderworkacc » Mon, Jul 18, 2022, 10:59 AM UTC

Retric wrote: post #23

userbinator wrote: post #14

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 issue for commercial cinemas is not necessarily handling storage and playback of DCinema packages - it’s the DRM that the studios insist upon playing nice with the projectors. Most cinemas converted their screens at least a decade ago, financed partly by distributors, and the industry is sort of stuck in time as a result.

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

#77

Post by faragon » Mon, Jul 18, 2022, 11:39 AM UTC

JPEG 2000 is used a lot in raster maps (satellite images, with jp2/ecw/sid containers)

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

#78

Post by buster3000 » Mon, Jul 18, 2022, 11:43 AM UTC

userbinator wrote: post #14

greenknight wrote: post #4

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.

we use comprimato which can use the GPU. It's very performant

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

#79

Post by swores » Mon, Jul 18, 2022, 11:48 AM UTC

notpushkin wrote: post #74

Shared404 wrote: post #34

Earlier quoted context omitted.

Commodity hardware doesn't require Windows... Though lets be honest, they'd probably use Windows anyways and that probably would happen.

A couple months ago, I've been to a 2020 anime feature film in a cinema here in Estonia. To my amusement, after the credits I was greeted with the VLC interface for a brief moment (though they've turned off the projector very quickly after that). Edit: obviously, that's not how most movies are shown here :D

I wonder if that was because that film's distributor is relaxed about DRM, or if the cinema just decided not to care about licensing it assuming that an Asian (I guess) IP holder would be unlikely to find out or take legal action against a small cinema in Estonia?

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

#80

Post by tgv » Mon, Jul 18, 2022, 12:42 PM UTC

fragmede wrote: post #58

tgv wrote: post #51

Earlier quoted context omitted.

Until we switch to another architecture. It's pretty likely the x86 architecture will be gone in a few decades. Rebuilding VM software to run on new hardware is probably harder than fixing bugs in a JPEG decoder.

A few decades? The IBM System/360 architecture is still being shipped, and that first shipped in 1965!

Nobody ships a PDP11 or VAX anymore. 6809? 6502? I think even the one ubiquitous 8080 isn't being produced anymore. And when IBM falls, System/360 will also be gone. There will be a transition period in which everybody scrambles to convert their systems, but after that it's EOL.