Real-Time Adaptive Image Compression

H4CK3RM4N wrote: post #4

creo wrote: post #3

Where is PNG?

I think this is lossy compression, so it doesnt really overlap w/PNG in terms of performance/file size goals.

Oh, right. I didn't consider that.

Re: Real-Time Adaptive Image Compression

#6

Post by madez » Thu, May 18, 2017, 8:54 AM UTC

boromi wrote: post #2

I'm going to need to see this code in practise to believe it.

I didn't find the code. Did you have more luck?

Re: Real-Time Adaptive Image Compression

#7

Post by hojijoji » Thu, May 18, 2017, 8:59 AM UTC

for some reaso they do not show the uncompressed image for comparison

Re: Real-Time Adaptive Image Compression

#8

Post by syberspace » Thu, May 18, 2017, 9:23 AM UTC

hojijoji wrote: post #7

for some reaso they do not show the uncompressed image for comparison

They mentioned the Kodak dataset[1] in the second paragraph. It seems to be Kodak Image 15[2]

edit: as for the other images: it would be indeed nice to see those.

[1] http://r0k.us/graphics/kodak/ [2] http://r0k.us/graphics/kodak/kodim15.html

Re: Real-Time Adaptive Image Compression

#9

Post by SimplyUnknown » Thu, May 18, 2017, 9:35 AM UTC

I wonder how this compares to FLIF. I also tried to compress images based on shape and structure but by approximating these using skeletons.

I'm just a bit struggling with their performance comparison. The graphs they present are very pretty and promising but for the presented images we're quite left in the dark. They dump some images and theirs looks prettier and the authors give us some indication of quality but it's not conclusive evidence that their method produces better images. Typically when different compressed images are presented two things can vary: quality and file-size. In the presented images both seem to varying without telling us which is which. Also, there is no baseline to compare against, either in terms of filesize or what the should look like. Sure, we humans can make a very educated guess but it is just sloppy to not include the uncompressed original image.

I will be fully convinced when I can try it for myself on my own image set.

Re: Real-Time Adaptive Image Compression

#10

Post by mcraiha » Thu, May 18, 2017, 9:44 AM UTC

One big reason for "hardcoded" encoders and decoders is that they much easier to implement in hardware.

One can improve e.g. H.265 somewhat easily, if software only solution is an option. But if you need cheap hardware only solution then ML-required-way seems a bit too expensive.