W3C home > Mailing lists > Public > www-svg@w3.org > September 2010

Re: Some comments on <image>

From: Alex Danilo <alex@abbra.com>
Date: Mon, 20 Sep 2010 11:39:19 +1000
Message-Id: <J9V09L.0PB5P6HEZ91@abbra.com>
To: "ddailey" <ddailey@zoominternet.net>
Cc: "Jeff Schiller" <codedread@gmail.com>, <anthony.grasso@cisra.canon.com.au>, "David Woolley" <forums@david-woolley.me.uk>, <www-svg@w3.org>
Hi David,

--Original Message--:
>> The spec. sets the minimum requirements. At the time the
>> spec reached recommendation, GIF was encumbered and a
>> poor image format anyway, so wouldn't have been included
>> for those reasons. There are clear rules about use of IP
>> encumbered things in W3C specs, hence why there is no
>> video codec mandated either...
>Understood. Does it deserve a revisit in light of the billion+ instances of 
>legacy content though? Maybe it's not a big issue, but the footprint of a 
>GIF unpacker is maybe less of a concern now?

It probably makes sense to raise it for SVG 2.0 I guess.

You can't retrospectively make this kind of change to a
recommendation so putting it in a future Rec track document
is OK.

PNG only exists because of the GIF issues anyway. So for
a future spec. it probably makes sense to at least formalize
it since there are unlikely to be any IP concerns anymore(*).

I don't see any future work being done on the mobile profiles
happening any time soon, so it's unlikely to have much
impact there.

But these pixel formats you're talking about - perhaps
we should deprecate them all...

I mean heck, we should encode everything in XML, which
is why years ago I came up with this brilliant idea to
generate paths around film grain particles - yes, that's
it. Film Grain Markup Language (FGML). Gets rid of all that
aliasing from pixels, and can scale. Oh yes, that's
right, the site http://fgml.org/ aims to pick up on this
new revolutionary technology.

Sorry I though it was April...

(*) The GIF implementation would need to be done from
scratch starting now - according to IP law you can't build
a product in anticipation of the IP expiring and then
bring it to market - that's considered infringement. So
time to read the GIF spec. and write a new library if
you really want to be safe. Nice, huh!

>[1]  http://srufaculty.sru.edu/david.dailey/engraver.htm
>[3] http://srufaculty.sru.edu/david.dailey/graphics/engravings.htm
>[4] http://srufaculty.sru.edu/david.dailey/public/public_domain.htm
>* Actually, if I were doing it seriously, then I'd want to scan in 48 bits 
>per pixel (8 bits per R, G and B and 8 each for ultraviolet, near and far 
>infrared, since that would have yet more archival value -- that was, at 
>least the plan for the Mongolian library back in 1988 since then you can do 
>some spectral analysis of the chemistry media -- but if we start talking 
>about supporting formats for 48 bit images on the web in SVG, then we'd 
>almost certainly have to start talking about an <animate> analog to the 
><replicatePath> tag so as to allow the plotting of those eight dimensions of 
>data in animated 3-channel two space.) 
Received on Monday, 20 September 2010 01:40:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:22 UTC