Re: Some comments on <image>

Hi David,

--Original Message--:
><snip/>
>> 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...

Alex
(*) 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!

>regards
>David
>
>[1]  http://srufaculty.sru.edu/david.dailey/engraver.htm
>[2] 
>http://srufaculty.sru.edu/david.dailey/graphics/scan/paterson/engraving_casestudyPaterson.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