Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is JPEG 2000 a preservation risk? (2013)

blogs.loc.gov

Post reply on HN
Print view View original

81–87 of 87 posts

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

#81

Post by usrn »

tgv wrote: post #80
fragmede wrote: post #58

Earlier quoted context omitted.

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.

I know someone who got hired recently to get PDP11 software running in an emulator to control an industrial process.

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

#82

Post by tgv »

usrn wrote: post #81
tgv wrote: post #80

Earlier quoted context omitted.

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.

I know someone who got hired recently to get PDP11 software running in an emulator to control an industrial process.

I expect that to happen to /360 as well (there's more than one emulator; there's even support for the old consoles), but the hardware will be gone. And --in case of the JPEG2000-- once x86 is gone, it'll be an old decoder running on an old, unsupported OS running on unmaintained VM software running on a hardware emulator (which will also have a limited support). Not a great outlook.

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

#83

Post by userbinator »

alophawen wrote: post #65
userbinator wrote: post #35

Earlier quoted context omitted.

The fastest decoder there uses the GPU, not the CPU. The fastest one that runs on a CPU, Kakadu (proprietary), is far behind.

> The fastest decoder there uses the GPU, not the CPU. How does that matter? It was a reply to your incorrect claim: > it's decoded by (no doubt extremely expensive) hardware

See here: https://news.ycombinator.com/item?id=32136471

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

#84

Post by boxerab »

It certainly was a risk in 2013, when the open source libraries were slow and riddled with bugs. Today, there are two stable, well maintained and fast open source libraries available:

https://github.com/uclouvain/openjpeg and https://github.com/GrokImageCompression/grok

JPEG 2000 is a niche codec, but in the niches that it occupies it is the gold standard, even after 20 years:

1. digital cinema (part of the digital cinema standard) and broadcast 2. medical imaging 3. satellite imagery

For memory institutions, it still vies with Tiff as the top preservation codec.

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

#85

Post by rasz »

eyelidlessness wrote: post #52
vitus wrote: post #44

Earlier quoted context omitted.

24fps is still standard for movies, in part because people have associated higher framerate video with amateur home video recordings so it looks cheap. :)

To elaborate on this, higher frame rate video registers the same way to people who aren’t aware that’s what they’re noticing. I was discussing this with my dad just a little over a week ago, where he noted some portion of a movie looked lower production than the rest of the movie. I had noticed it too, because it was visibly higher frame rate. Lower frame rates more closely match the visuals of film, and higher frame…

Thankfully this changes with latest generation brought up on 60fps YT and Twitch.

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

#86

Post by lajt »

astrange wrote: post #54
lajt wrote: post #28

We're building an iPad reader app that uses Apple's PDFKit, but we encountered JPEG2000s in the PDFs of the client's library, and PDFKit doesn't render them correctly. The frustrating thing is we're stuck with the issue since it's such a niche case that I don't think Apple will ever fix it. There is a 3rd-party commercial library PSPDF for iOS that renders it right, but I don't think they want to pay for it.

This may be fixed in the newest macOS betas. The manual for my car wasn't rendering before and now is.

Hey thanks for letting me know! That's great to hear. I'll keep an eye on it.

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

#87

Post by gwern »

prvc wrote: post #5
gwern wrote: 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% (!).

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.

I don't think it's common. I've wondered for a long time why every time I try to process or edit an IA book scan - and only IA book scans - they come out bizarrely mangled and broken and inconsistent across viewers (and have mostly given up using them and scanning books myself), slow and surprisingly bulky compared to normal JBIG2-compressed JPEG PDFs. OP's observations about the unreliability and inconsistency of JPEG2k across tools would explain all of this...
Post reply on HN