HEVC image in 140 character tweet

[Parabola]

Not quite "video" but our latest blog entry (http://www.parabolaresearch.com/blog/2013-10-21-hevc-over-twitter.html)may be of interest here:

http://www.parabolaresearch.com/mona_lisa_fig3c.jpg

Just for fun, we tried to send the Mona Lisa via a single tweet by compressing her using HEVC Intra Still Picture.

I'm sure HEVC has more to give here and can convincingly beat DLI but maybe it will take a little time for optimized encoders to appear...

[birdie]

Now release an image codec bases on HEVC, please. Webp is good (in lossy mode it easily beats JPEG, in lossless mode it often beats PNG), but I guess HEVC will be even better.

I've been asking for that for months.

[raffriff42]

Quite cool, but someone is bending the rules a little. SMS is limited to 140 octets, not 140 multibyte characters (251 bytes)

Short_Message_Service#Message_size (http://en.wikipedia.org/wiki/Short_Message_Service#Message_size) (Wikipedia) Messages are sent with the MAP MO- and MT-ForwardSM operations, whose payload length is limited by the constraints of the signaling protocol to precisely 140 octets (140 octets = 140 * 8 bits = 1120 bits). Short messages can be encoded using a variety of alphabets: the default GSM 7-bit alphabet, the 8-bit data alphabet, and the 16-bit UCS-2 alphabet.[40] Depending on which alphabet the subscriber has configured in the handset, this leads to the maximum individual short message sizes of 160 7-bit characters, 140 8-bit characters, or 70 16-bit characters.



Here is my entry - ASCII art !! ®;;:
¤~ ~H8±
: £{ ~N±£;
£ ;; ¤L~ª~£¤N6~;
{;:£~£6L : ¤M2~ª ,
&¤£¤£¤NML~;%06N¤£~©:
¤^\£~£26M¾~~~G0M££®
£¤{°&&N~ ¤MH¢¢:~
£{£GNN¤¤;;;;¤0N2NN£:
{ ;HGN86NGQ8NNQQMM£|
1&OHM6NQGNWNN6±8NMW¤
£WGW¢;; ~^NMNMNMNN¢
¤NNQP^:; ;\£UNNW±0QQ
NNQ8N£QNNWN88±±±±±W0This zips down to 343 bytes, so it needs some work ;)

[Procrastinating]

Besides character limits, twitter doesn't really have all that much to do with sms. Any character that can be represented by the font on twitter, can be used in our tweetP files.
Think of it as a secondary challenge to make the most of the capabilities within twitter itself.

Now all we have to do is write a greasemonkey script that detects and converts tweetP images on the fly :'D


It will also be interesting to see what it will look like when better profiles are added like 10+bit and 4:4:4 colour, which can be better quantized. Maybe you could shave enough bytes off of that hand-optimized pic.

I'm kinda liking the idea of using the twitter picture as the big-mac index of lossy encoding. Doesn't really mean much, but gives a tasty insight into how they perform.

[Parabola]

Like the idea of the Big Mac index of lossy image encoding. Very visual.

Just read that the DLI codec was used on an image resized to 61x90 or so... we are using a much higher HEVC resolution and maxing out Qp. Suspect downsizing [more] to width of 64 would help but too busy to try....

[dapperdan]

I'm sure HEVC has more to give here and can convincingly beat DLI but maybe it will take a little time for optimized encoders to appear...

Is that likely? I thought DLI, by nature of its single-minded purpose would always beat HEVC, which is a lot more constrained in encode and decode time.

Strange that I see the two image codecs mentioned together, I was thinking about running Mozilla's lossy image test against DLI until I realized they only provide Windows binaries.

https://blog.mozilla.org/research/2013/10/17/studying-lossy-image-compression-efficiency/

[Parabola]

You don't have to constrain encode time if you're dealing with a still image one-off encode. Could do all sorts of iterative or Viterbi type algorithms. Also I think a higher lambda over Mona Lisa's face wouldn't hurt.

[pieter3d]

Too bad the SPS,PPS and slice header are relatively large in this stream, taking up valuable bits.

[DiKey]

Why there is no any HEVC photo viewer/encoder?

[benwaggoner]

Why there is no any HEVC photo viewer/encoder?
Because no one has written one yet? Although I think that x265 can use Main Still Profile.

If you stick a single frame of HEVC into a .mp4 file, any number of HEVC decoders would play back that frame.

I do hope something comes of it. H.264 High Profile I-frames were a very promising alternative to JPEG with broad hardware decode support, but it never really caught on as an image-only format. HEVC is a lot better yet, particularly for large frame sizes.

[foxyshadis]

Anyone who wants to can use VLC, ffplay, or any other lightweight video player as a HEVC picture viewer already. They might even support raw bitstreams. Writing plugins for dedicated image viewers takes time and interest, first.

A downside is that Main Still requires 8-bit pictures only, there's no Still 10. :( I would use Main 10 and pretend it's the same thing. The one and only difference between Main and Main Still is "The bitstream shall contain only one picture," which is obvious.

The mp4 container is flexible enough to support as many single-picture bitstreams as anyone needs for thumbnails, picture collections, etc. An important factor will be standardizing how EXIF, IPTC, and thumbnails are included in mp4, which HEVC obviously isn't concerned about. That's already been done for matroska thanks to WebP. I wonder what the overhead difference is.

[Daemon404]

That's already been done for matroska thanks to WebP. I wonder what the overhead difference is.

WebP uses RIFF, not Matroska.

[pieter1976]

I have tried to accomplish similar result as the 'HEVC image in 140 character tweet'.

And I have come up with the following strategy.

1. lets take 14 by 21 pixels and use 32 palettized colors.
2. This is 14*21*5=1470 bits, add 32*24 equals 768 bits for the palettized colors.
3. The total is 2238 bits or 280 bytes

The result is like a gif format file without the header and the binary compression.

Here is the result:

http://i40.tinypic.com/jpg1i1.jpg

Scale by an advanced scaler (http://www.general-cathexis.com/)

http://i42.tinypic.com/xncirs.jpg