Re: Some comments on <image>

Ales wrote:

> Most mobile browsers won't.
>
> This is to minimize memory footprint more than a technical
> issue.

Ahh! That makes sense.

> But GIF isn't continuous tone - it's a palleted colour
> format so is pretty lame.

Yeah, generally I concur. The one exception I've found is for greyscale 
scans of old engravings [1,2,3], though maybe David Woolley can find a 
palleted solution within a subformat of PNG for images such as in [4] . The 
engraving lines have typically been cast at a spatial resolution of about 
200 lines per inch maximum (less for master engravers like Durer whose eye 
for contour-normal gradient vectors seems more trained than for the meat and 
potatoes engravers of the late 1800's printing industry.) Scanning at 400 
dpi to accomodate up to 200 strokes per inch blows up the image size in any 
format and is frankly overkill since the information gain is negligible with 
the only benefit being the amplification of impurities in the paper and 
discoloration effects due to aging of the media. But if one increases the 
bits per pixel from the original monochrome bitmap to say 3 bits, then the 
tradeoff in terms of file size is quite respectible and, at the same time, 
one can preserve the semantic gist of the engraving strokes. It is a rare 
engraving that requires more than 150 dpi at 4 bits per pixel. Were I doing 
this work today, 20 years later*, I would probably just scan at 400 dpi at 
24 bpp in a lossless format and then thumbnail my way down to the user from 
there, since most folks are no longer so annoyed at the prospect of 
downloading a 20 MB image, if indeed they want it, but those intermediate 
stages of resolution (between thumbnail and archival image) that are needed 
for the user to assess his interest level, are still problematic.

> 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?

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:28:05 UTC