[usf-devel] Re: [png-list] Request for a hi-speed bitmap compression format standard
- From: Glenn Randers-Pehrson <glennrp@xxxxxxxxxxx>
- To: png-list@xxxxxxxxxxxxxx
- Date: Wed, 13 Aug 2003 11:24:55 -0400
At 01:14 PM 8/11/03 +0200, Christian HJ Wiesner wrote:
[long explanation omitted.. see archives...]
>Now, after this long explanation, here my questions to you guys :
>
>1. Is there any chance to make PNG much faster than it currently is,
>even with the disadvantage of a much lower compression ratio than what
>you guys normally achieve, but still be PNG spec compliant ? To be more
>precise, the PNGs created with our 'special' compressor should be
>decodable by any existing PNG decompressor lib, even when being slow. Of
>course, we know we have to use a special modified lib for decompressing
>at the desired high speed in real time, to gain the speed advantage, but
>thats ok with us.
I don't think so.
>2. If 1. is not possible, how big are the chances to think of an
>extention to the format, lets call it F-PNG ( Fast PNG ), and add this
>to the official PNG specs ? I am pretty sure, there is other use for
>such a format also.
The best approach would be to go ahead and make a private extension
(compression method=128) and test it in your application. After successful
demo and usage, propose the extension to this group.
>3. We get a lot of requests from people creating their own subtitles for
>movies, but who make those with special ( even grafical ) tools to
>achieve fancy features, like highlighting words or syllables for
>karaoke, etc. . It is possible to include special scripting languages
>into our container to display those tracks that way, but as the text is
>UTF8 or UF 16 in most cases there is still a big problem to display
>those correctly on any computer ( font problem, etc. ).
This sounds like something that can be done in SVG. PNG doesn't offer
anything like this at present, but it could be done with a special
PNG/MNG chunk or chunk set.
> Using picture
>subs would help here a lot, but with normal BMPs, even RLE compressed,
>the size will become HUGE in the end, as every single change of the
>subtitle requires a new bitmap, so the size of such an 'enhanced' track
>can easily be 10x the one of a normal, and 50 - 80 MB for a subtitle
>track with RLE compression, or even 7 - 10 MB with lzo is absolutely
>unacceptable in most cases. Could a fast version of MNG ( call it F-MNG
>) be used to bring this size down significantly ?
My answers about PNG also apply to MNG.
It would be interesting to see speed results for LZW (GIF) compared to
your other tests. LZW becomes available for free use world wide next
summer.
Glenn
http://usf.corecodec.org
Other related posts:
