[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Alternative compression scheme.
- To: Chris Marrin <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] Alternative compression scheme.
- From: Steve Baker <email@example.com>
- Date: Fri, 03 Dec 2010 18:55:00 -0600
- Cc: public webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=sjbaker.org; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sjbaker.org; bh=BUd/9 2lEejQJ1Zb/E56a3WQuko4=; b=hNoY3VtKeyDQoW95rPOIzQQsUVOtIX8L7oluh EytY2bBlNHNzACT+t2CKiQNuuWoexNf+tgUMXNlrueBfDwwDlQMwUHZY7dlo3qa9 I9yRZotqnpxRa/6Am4CnAJVoKRe2cwCSmRG2pvc283iZ51NGHFdt0MF4PD/VYzJ4 6r24y0=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=sjbaker.org; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sjbaker.org; b=MiRfkKarJ+USXVvaDvp6pN5bs3bcti4YHTgFIhknCY2bkfEc9+0tvlxRtVLyq L9wv6GDw0Ick5pngv3SPyV7oQ4bubaIjjDMbx6DB8Gmw2XmztUK/uFeymW+pag8c RjJPr72m13usDb7r1UEcjhNrEqfxY6ErjE3QCOzFsKnObA=
- In-reply-to: <933CF6D6-35E8-4081-84AE-7EF3A66A2378@apple.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <4CF8910E.email@example.com> <933CF6D6-35E8-4081-84AE-7EF3A66A2378@apple.com>
- Sender: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:184.108.40.206) Gecko/20100520 SUSE/3.0.5 Thunderbird/3.0.5
On 12/03/2010 06:25 PM, Chris Marrin wrote:
> On Dec 2, 2010, at 10:41 PM, Steve Baker wrote:
>> I don't know whether there is any interest in this - but I guess I could
>> suggest another lossy compression scheme for WebGL textures based on
>> simple dictionary compression.
>> The reason I propose it in the teeth of so many other lossy image
>> compression schemes such as JPEG, WebP, DXT and ETC is that this scheme
>> can be decoded in the shader - either as a one-time step to avoid
>> as the image is rendered.
>> The idea is to chop your image into (say) 4x4 pixel chunks - and make a
>> list of them. The file itself consists of the list of 4x4 chunks (the
>> dictionary) - plus a 2D array of indices that point into that dictionary.
>> The size of the resulting file is (16*DictionarySize*Sizeof(Pixel)) +
>> (ImageSize*log2(DictionarySize)/26) ...which is (in practice) dominated
>> by the first term - the space consumed by the dictionary.
>> To avoid having to invent new file formats - you can store this as two
>> separate maps - one containing the dictionary and the other containing
>> the index array. Both of those could be stored as .PNG or whatever.
> Do you have a patent on this format?
No - I don't.
> If not, it's likely that the owners of other patented formats could come after you, making this format unusable. In particular you concept of splitting an image into smaller squares and encoding must fall well within the JPEG and MPEG patents.
Really? There are lots of compression schemes that do that (ETC and
DXT/S3C, to name but two). It's hard to imagine that such a very
basic/obvious idea used across so many competing file formats would be
patentable. IANAL though...who knows?
> For some reason I've seen lots of people lately saying, "the web is full of patented technologies, let's make something just as good that's not patented". Their solution until a company owning the patents decides to go after them. There are several formats on the web today. Just because someone hasn't gone after them yet, doesn't me someone won't. GIF was ruined this way.
Yep...it's basically a mess. But the reason people say this is that
there is really no other choice. What can you do? Standards for the
web have to be free in order to get W3C backing. So we can't use DXT
(which could have been ideal). ETC isn't very useful because it fails
miserably for anything other than RGB photographs (although maybe there
is hope for ETC2). Nothing that has hardware support is available to
WebGL. What choice do we have but to try to come up with something
that's patent-free and could be decoded on-the-fly in the GPU?
> We may not like the prevalence of patent encumbrances on what we do. But they're there and we have to deal with that.
Indeed. Well, I only offer this as a suggestion - if it's already
covered by some other patent then it's no good - but I don't have the
patent-lawyer skills at reading turgid/obfuscated English - or the
patience to check through a bazillion dusty old patents.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: