[HN Gopher] Silly Image Compression Idea
___________________________________________________________________
Silly Image Compression Idea
Author : sn_fk_n
Score : 27 points
Date : 2022-04-10 17:04 UTC (5 hours ago)
(HTM) web link (snufk.in)
(TXT) w3m dump (snufk.in)
| can16358p wrote:
| This reminded me of a weird idea that I had several years ago
| (which is kind of opposite of this):
|
| What if there was a format that doesn't encode pixels but
| generates a "description" of the images using AI, of simple
| shapes to higher-level objects, and saves that in its own format,
| with a "decoder" that takes this input description format and
| constructs an image similar to the original, at least to some
| extent.
|
| Of course this would have many drawbacks like encoding micro
| details and expressions of people, but still, I'd love to see how
| far the idea can go.
| ausbah wrote:
| sounds like vector graphics?
| pavlov wrote:
| This could be useful to reduce Disney's bandwidth costs. Marvel
| and Star Wars productions are highly repetitive anyway, so
| maybe they could ship a preloaded Marvel neural network in the
| player app and design new movies to take maximum advantage of
| the cliches already encoded there.
| forgotusername6 wrote:
| They used to literally reuse the animation in older Disney
| films, just with different characters on top. You could send
| that information, the scene and the characters, in
| significantly fewer bits than it would take as video
| magicalhippo wrote:
| Not entirely unlike fractal compression[1]. Was a lot of hype
| around it way back, but clearly it didn't quite pan out.
|
| [1]: https://en.wikipedia.org/wiki/Fractal_compression
| gfody wrote:
| that's roughly the idea for gan-based image compression, check
| out: https://data.vision.ee.ethz.ch/aeirikur/extremecompression
| steanne wrote:
| that's like heraldry, rebuilding an image from a
| precise/regimented verbal description
| gjvnq wrote:
| It's called SVG :)
| sbierwagen wrote:
| Venor Vinge, A Fire Upon The Deep (1992):
|
| >Fleet Central refused the full video link coming from the Out
| of Band ... Kjet had to settle for a combat link: The screen
| showed a color image with high resolution. Looking at it
| carefully, one realized the thing was a poor evocation.... Kjet
| recognized Owner Limmende and Jan Skrits, her chief of staff,
| but they looked several years out of style: old video matched
| with the transmitted animation cues. The actual communication
| channel was less than four thousand bits per second
|
| >The picture was crisp and clear, but when the figures moved it
| was with cartoonlike awkwardness. And some of the faces
| belonged to people Kjet knew had been transferred before the
| fall of Sjandra Kei. The processors here on the Olvira were
| taking the narrowband signal from Fleet Central, fleshing it
| out with detailed (and out of date) background and evoking the
| image shown.
| pizza wrote:
| PixelCNN++ does this, kinda. Residual blocks that use downsampled
| versions of the image. Though in that context, it gets used for
| lossless compression by entropy coding the likelihoods of each
| pixel.
|
| This idea - trying to investigate behavior at different scale
| parameters - is also related to renormalization. But I think you
| can go further than this - currently you are just preserving that
| which remains consistent. You should also somehow store the
| complement of that information - the difference between the
| original and what you get after downscaling then upscaling the
| downscaled version again.
|
| I imagine it's going to be mostly the noisy data local to certain
| regions of the image, some kind of high frequency details. But if
| you keep track of both, you can make each rescaling bijective,
| making your 'compression' invertible, hence lossless, in some
| sense. Whether you get any size savings doing that is another
| question altogether :^)
| melony wrote:
| Congrats on reinventing the autoencoder!
| canjobear wrote:
| This isn't an autoencoder.
| kazinator wrote:
| > _What would image compression look like if designed around
| other things perceptions?_
|
| If the other creature's vision is in a different wavelength
| range, then RGB images are not applicable to it at all, in the
| first place.
| malkia wrote:
| That's "dictionary" compression still. AI checks for hints to
| lookup in well... dictionary. If the dictionary changes, your
| compression results change too.
| nullc wrote:
| the smallest compressor is just the (differentiable) classier
| itself. The compressed image is just the output class, and the
| de-compressor generates a random image then back propagates the
| class error until it gets an image that has the right class.
| Maybe you toss in a random seed in the format, so the compressor
| can spend some more time to guarantee the de-compressor will
| complete in a reasonable amount of time.
| klyrs wrote:
| Compression with no plan in sight for decompression... at least
| it's billed as "silly" first and foremost.
| jtsiskin wrote:
| Compression doesn't imply decompression... see JPEG, H264,
| etc...
| dahart wrote:
| Maybe you could elaborate... what do you mean? Both of those
| examples (JPEG, H264) have decompressors for viewing, right?
| elpocko wrote:
| I've seen worse; someone presented code for decompression of a
| fictional data format with no plan in sight for compression.
|
| When I asked how the compression part would be implemented, the
| author called me stupid for asking this question and told me
| the project was inspired by
| https://en.wikipedia.org/wiki/Sloot_Digital_Coding_System
| klyrs wrote:
| That is simply amazing, thanks for sharing :)
___________________________________________________________________
(page generated 2022-04-10 23:00 UTC)