- From: Alex Danilo <alex@abbra.com>
- Date: Mon, 20 Sep 2010 11:39:19 +1000
- 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--: ><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