Live data from Hacker News

Compressing Images with Neural Networks

mlumiste.com

71–75 of 75 posts

Re: Compressing Images with Neural Networks

#71

Earlier quoted context omitted.

Not the parent but one imagines that WASM could be a good target for decompressing or otherwise decoding less-adopted formats/protocols because WASM is fairly broadly-adopted and seems to be at least holding steady if not growing as an executable format: it seems unlikely that WASM disappears in the foreseeable future. Truly standard ANSI C along with a number of other implementation strategies (LLVM IR seems unlikel…

Wasm is simple, well-defined, small enough that one person can implement the whole thing in a few weeks, and (unlike the JVM) is usable without its standard library (WASI). LLVM isn't as simple: there's not really such thing as target-independent LLVM IR, there are lots of very specific keywords with subtle behavioural effects on the code, and it's hard to read. I think LLVM is the only full implementation of LLVM. (…

I think we probably agree about most things but I’ll nitpick here and there.

ANSI C is among the simpler languages to have serious adoption. It’s a bit tricky to use correctly because much of its simplicity derives from leaving a lot of the complexity burden on the author or maintainer, but the language specification is small enough in bytes to fit on a 3.5” floppy disk, and I think there are conforming implementations smaller than that!

You seem to be alluding to C getting replaced by Rust as that’s the only other language with so much as a device driver to its name in the Linux kernel. Linus is on the record recently saying that it will be decades before Rust has a serious share of the core: not being an active kernel code tribute I’m inclined to trust his forecast more than anyone else’s.

But Rust started at a complexity level comparable to where the C/C++ ecosystem ended up after 40 years of maintaining substantial backwards compatibility, and shows no signs of getting simpler. The few bright spots (like syntax for the Either monad) seem to be getting less rather than more popular, the bad habits it learned from C++ (forcing too much into the trait system and the macro mechanism) seem to have all the same appeal that template madness does to C++ hackers who don’t know e.g. Haskell well. And in spite of the fact that like 80% of my user land is written in Rust, I’m unaware of even a single project that folks can’t live without that’s married to Rust.

Rust is very cool, does some things very well, and it wouldn’t be hard to do a version of it without net-negative levels of opinionated on memory management, but speaking for myself I’m still watching Nim and V and Zig and Jai and a bunch of other things, because Rust takes after its C++ heritage more than its Haskell heritage, and it’s not entrenched enough in real industry to justify its swagger in places like HN.

The game is still on for what comes after C: Rust is in the lead, but it’s not the successor C deserves.

Re: Compressing Images with Neural Networks

#72
post #64
post #51

Earlier quoted context omitted.

The suitable lossy-ness (of any compression method) is entirely dependant on context. There is no one size fits all approach for all uses cases. One key item with emerging 'AI compression' techniques is the information loss is not deterministic which somewhat complicates assessing suitability.

> the information loss is not deterministic It is technically possible to make it deterministic. The main reason you don't deterministic outputs today is that Cuda/GPU optimizations make the calculations run much faster if you let them be undeterministic. The internal GPU scheduler will then process things in the order it thinks is fastest. Since floating point is not associative, you can get different results for (a…

The challenge goes beyond rounding errors.

Many core codecs are pretty good at adhering to reference implementations, but are still open to similar issues so may not be bit exact.

With a DCT or wavelet transform, quantisation, chroma subsampling, entropy coding, motion prediction and the suite of other techniques that go into modern media squishing it’s possible to mostly reason about what type of error will come out the other end of the system for a yet to be seen input.

When that system is replaced by a non-linear box of mystery, this ability is lost.

Re: Compressing Images with Neural Networks

#73
post #10

Anyone know of open models useful (and good quality) for going the other way? I.e., Input is a 800x600 jpg and output is 4k version.

This is called super resolution (SR). 2x SR is pretty safe and easy (so every pixel in becomes 2x2 out, in your example 800x600->1600x1200). Higher scalings are a lot harder and prone to hallucination, weird texturing, etc.

Re: Compressing Images with Neural Networks

#74

Earlier quoted context omitted.

Wasm is simple, well-defined, small enough that one person can implement the whole thing in a few weeks, and (unlike the JVM) is usable without its standard library (WASI). LLVM isn't as simple: there's not really such thing as target-independent LLVM IR, there are lots of very specific keywords with subtle behavioural effects on the code, and it's hard to read. I think LLVM is the only full implementation of LLVM. (…

I think we probably agree about most things but I’ll nitpick here and there. ANSI C is among the simpler languages to have serious adoption. It’s a bit tricky to use correctly because much of its simplicity derives from leaving a lot of the complexity burden on the author or maintainer, but the language specification is small enough in bytes to fit on a 3.5” floppy disk, and I think there are conforming implementatio…

Yeah, Rust may be a suitable C++ replacement, but it's not a suitable C replacement. (Arguably, C isn't a suitable C replacement…)

Re: Compressing Images with Neural Networks

#75

Earlier quoted context omitted.

I think we probably agree about most things but I’ll nitpick here and there. ANSI C is among the simpler languages to have serious adoption. It’s a bit tricky to use correctly because much of its simplicity derives from leaving a lot of the complexity burden on the author or maintainer, but the language specification is small enough in bytes to fit on a 3.5” floppy disk, and I think there are conforming implementatio…

Yeah, Rust may be a suitable C++ replacement, but it's not a suitable C replacement. (Arguably, C isn't a suitable C replacement…)

You've made the point much, much better than I did. Well said.
Post reply on HN