HTTP and no inline JPEGs???
John Churchill
of this, I have to use inferior GIF files that look nowhere as good and
are nearly ten times as large. Really, how hard would it be to put a
JPEG decoder in Mosaic? It would easily cut the amount of Mosaic-related
traffic on the internet in half and encourage everyone to leave the
auto-load images switch on.
Marc VanHeyningen
c.i.w; I'd like to see this posting saved and held up as an example of
how to lool like a jerk. Let's see how many of the standard,
tried-and-true assertions are contained in it...
Thus said John Churchill <bone...@ccwf.cc.utexas.edu>:
>Who's the idiot who decided that Mosaic wouldn't handle JPEGs?? Because
Is that username a joke, by the way? Your sendmail daemon confirms it
as an accurate address, or else I'd dismiss this posting as forged
flamebait. It seems so apt...
Ah! Flaming and namecalling people who make a product available to
you for free! That's worth at least 4 points on the jerkometer. If
you don't like their product, don't use it, or demand a refund, or use
something else that you think is better, or make constructive
suggestions. But there's no need to be insulting.
Also: complaining about Mosaic without specifying whether it's Mosaic
for Windows, Mosaic for the Mac or Mosaic for X. That's another 1 point.
>of this, I have to use inferior GIF files that look nowhere as good and
>are nearly ten times as large. Really, how hard would it be to put a
Silly assertions about relative sizes of image files and quality,
which are totally irrelevant to Mosaic because the colormap is trimmed
down so much for inlined images that the quality difference between
GIF and JPEG is almost totally lost! Another two points!
>JPEG decoder in Mosaic? It would easily cut the amount of Mosaic-related
Well, assuming you mean Mosaic for X (which most people who don't
specify which one mean) the full source is available. If it's so easy
to add JPEG support, why don't you do so and post the patches? One
more point.
>traffic on the internet in half and encourage everyone to leave the
>auto-load images switch on.
And, finally, the assumption that everyone is using a machine capable
of decompressing and displaying JPEGs rapidly. Many people have fast
links and slow machines, and the time saved on the transfer would be
more than lost by the time wasted doing the decompression. One more
point.
That's a total of 9; pretty impressive! However, I should think
future posts might do better; there are some important points that
could be included:
- In addition to calling the NCSA developers idiots, you should flame
them for not instantly responding to email with half-descriptions of
problems, bugs, or limitations in their products.
Also, you may wish to flame them for using Motif, for not setting up
a system in which one can easily use their product over a straight
dialup without the inconvenience of establishing TCP/IP
connectivity, or for being agents of the devil.
- You should talk about using "Mosaic servers", and mention more
buzzwords like "Information superhighway" and "500 channels."
- You should find some feature that has been in the spec for a long
time (e.g. the HEAD method, or the Expires: and Last-Modified:
headers) and insist that HTTP is lousy because it can't do this.
And on and on; think up your own at home, kids! It's fun!
comp.infosystems.www.flame, anyone? :-)
--
Marc VanHeyningen mvan...@cs.indiana.edu MIME, RIPEM & HTTP spoken here
Jon E. Mittelhauser
>This is, I think, an excellent example of a net.moron posting to
>c.i.w; I'd like to see this posting saved and held up as an example of
>how to lool like a jerk. Let's see how many of the standard,
>tried-and-true assertions are contained in it...
Wow. Thanks Marc. This made my night. I won't even bother replying to
the original because you did a better job than I could ever hope.
I might note that HTTP has nothing to do with whether or not JPEGs are
supported in Mosaic. Even HTML doesn't although it is closer. The
best argument that I have heard for JPEGs was the people who had to
pay on a per byte cost. The decision to not (immediately) support
JPEGs had to do with the assumed bandwidth of people using Mosaic. On
a direct net connection, the time to decode the JPEG (compared to GIF)
is long enough to compensate for the net transfer. If we assume that
people are using a phone line (as is increasingly- unfortunately- becoming
the case) this is no longer true.
JPEG support would be nice. I, personally, would like it. However,
people like the original poster would be better off giving arguments for
it and nice request than the stupid approach of flaming the developers
for their choices. Limited resources and all that... :^)
-Jon
John Churchill
jo...@void.ncsa.uiuc.edu writes:
>I might note that HTTP has nothing to do with whether or not JPEGs are
>supported in Mosaic. Even HTML doesn't although it is closer. The
>best argument that I have heard for JPEGs was the people who had to
>pay on a per byte cost. The decision to not (immediately) support
>JPEGs had to do with the assumed bandwidth of people using Mosaic. On
>a direct net connection, the time to decode the JPEG (compared to GIF)
>is long enough to compensate for the net transfer. If we assume that
>people are using a phone line (as is increasingly- unfortunately-
becoming
>the case) this is no longer true.
I don't pay by the byte, but I am concerned about the time it takes to
download the graphic. I usually run with the auto-load switch off
because I don't want to wait. My experience with a dial-up SLIP at
14.4kbps has been approximately 1K per second, and perhaps 3 times faster
on a direct connection (which seems to come in as bursts). A particular
file that I want to use is 233K 24-bit, 12K as a JPEG with slight quality
loss, but a whopping 75K as an 8-bit indexed GIF file which looks worse.
This means for a dial-up user it would take 75 seconds to display the
GIF, but only 12 seconds to display the better-looking JPEG. Even with a
direct link, the time can be frustrating.
The potential user of the WWW server was my primary concern, because the
textual content on this server is boring and needs the graphics to drive
the message home, and that isn't going to happen if the user doesn't feel
like loading the graphics. Secondary to this was internet bandwidth. If
the decision not to support JPEG was based on assumed bandwidth and
tradeoff with processing power of slow machines, why is there so much
concern over "wasted bandwidth?" Wasn't that the reason for distributed
mirrors of popular archives and news servers?
Mike Meyer
> The potential user of the WWW server was my primary concern, because the
> textual content on this server is boring and needs the graphics to drive
> the message home, and that isn't going to happen if the user doesn't feel
> like loading the graphics.
Marc, you missed one - he also assumes that everyone uses the same
browser. A fair percentage of my users run Lynx, and I use the emacs
w3 browser about half the time. Since those browsers can't display an
inlined image, your inlined images won't do much for those readers.
You really need to work on making your text better. Better yet, do
both - put in the jpeg images you want, because some browsers can
display them, but also put in "alt" text (or use the html+ image tag)
to let people using browser that can't display those images know whats
going on.
<mike
William M. Perry
MM> In <2oao8t$l...@geraldo.cc.utexas.edu>, John Churchill
MM> <bone...@ccwf.cc.utexas.edu> wrote:
>> The potential user of the WWW server was my primary concern,
>> because the textual content on this server is boring and needs
>> the graphics to drive the message home, and that isn't going to
>> happen if the user doesn't feel like loading the graphics.
MM> Marc, you missed one - he also assumes that everyone uses the
MM> same browser. A fair percentage of my users run Lynx, and I
MM> use the emacs w3 browser about half the time. Since those
MM> browsers can't display an inlined image, your inlined images
MM> won't do much for those readers.
Well, for those people running lucid emacs, the emacs-w3 browser
will do inlined anything (from postscript to jpeg to group-3 faxes :)
with the help of the pbmplus package of graphics utilities.
Word is that FSF emacs 19 will eventually be able to do this also.
-Bill P.
Michael F. Maggard
bone...@ccwf.cc.utexas.edu writes:
>I have to use inferior GIF files that look nowhere as good
> and are nearly ten times as large.
Actually, the vast majority of inlined images are things like buttons,
horizontal bars, logos, and other geegaws that are perfectly suited for
GIFFs (their proper acronym.) Few of these images require more then 256
colors, have much complexity (meaning they're generally solid color
fields clearly bounded) and contain text and other detailed material that
most don't want 'lost' in compression.
Such GIFFs not only render quicker on most systems but are indeed often
smaller then a comperable JPEG compressed image. Indeed, I make it a
rule to supply an inlined thumbnail anchor to a seperate higher quality
fullsized image. This saves my reader from having to wait for graphics
they may not specifically want (btw, these higher quality images are
often GIFFs themselves, as they're usually diagrams and other 'artifical'
artwork that are best served by this format.) This is actually a benefit
to most as when these images are requested they're handed off to a
program that will do a far better job of displayng and manipulating them
then we could expect a Mosaic client to do.
Of course, GIFFs do fall short when it comes to 24 bit images (they're
limited to 8 bits (but then, the majority of readers are also still
limited to 8 bit displays)) or 'natural' images like photographs and
such. However, I've rarely found the need to do an *inlined*
high-quality photograph and frankly I'm happy to not be subjected to an
endless series of pages covered with unnecessary elaboration (a picture
may be worth a 1000 words - but what do we do when it 'costs' 1000^2
words ?)
Michael F. Maggard / mic...@zipper.pn.com / b2 f g++(+?) l+ k+ s+
r+
Piglet sidled up to Pooh from behind. "Pooh !" he whispered. "Yes, Piglet
?"
"Nothing," said Piglet, taking Pooh's paw. "I just wanted to be sure of
you."
Vern Hart
- GIFFs (their proper acronym.)
No, they are called GIF's. Only one F according to CompuServe.
--
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: Vern Hart 114 S Almon Apt A ::
:: Cactus Computer Company Moscow, ID 83843 ::
:: har...@uidaho.edu @University of Idaho (208)882-8508 ::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: The opinions and facts express above are in no way related to any ::
:: company or university I am currently employed with or attending. ::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Zach Baker
Vern Hart <har...@cs.uidaho.edu> wrote:
>Michael F. Maggard (mic...@zipper.pn.com) wrote:
>- GIFFs (their proper acronym.)
>
>No, they are called GIF's. Only one F according to CompuServe.
>
I believe what was meant was:
GIFF == Graphic Interchange Format File
Thus, one can speak of exchanging a GIF file or simply a GIFF.
vvv
Zach Baker Harvey Mudd College zba...@hmc.edu
"SCIENCE DOES NOT REMOVE THE TERROR OF THE GODS."
Sean Casey
be a good idea. GIF is better for a lot of the things out there, but
JPEG is better for pictures, which I am finding show up a lot as
inline images.
And let's face it, we're all going to 24 bit color eventually, and
processors are only going to get faster, not slower. The only thing
for certain is that we're going to keep the network saturated with
traffic.
So I hope there's some work being done in this direction. Compared
with the current size of the code, adding an inline JPEG converter is
a trivial increase, and something which is well supported with the
public JPEG project.
Sean
--
``Wind, waves, etc. are breakdowns in the face of the commitment to
getting from here to there. But they are conditions for sailing -- not
something to be gotten rid of, but something to be danced with.''
Steven Grimm
>As long as most people
>have relatively slow machines with 8-bit color, inlined JPEGs will be
>much slower to display and not appreciably better quality than GIFs;
I'd rather spend 15 seconds waiting for an inline JPEG to decompress than 30
waiting for the much larger GIF to come over my clogged, slow net connection.
I don't care a whit that JPEG is a 24-bit standard as opposed to an 8-bit
one; all I care about is its far superior compression. I expect that's true
of most of the folks who're advocating inline JPEGs here.
Especially for home users, I think it'll often be the case that bandwidth
is in shorter supply than MIPS, something that seems to be lost in this
discussion as people talk about whether we really need 24-bit inline images.
Color resolution is not why we want JPEG.
-Steve
Marc VanHeyningen
>In <24157.7...@hound.cs.indiana.edu> Marc VanHeyningen <mvan...@cs.indiana.edu> writes:
>>As long as most people
>>have relatively slow machines with 8-bit color, inlined JPEGs will be
>>much slower to display and not appreciably better quality than GIFs;
>
>I'd rather spend 15 seconds waiting for an inline JPEG to decompress than 30
>waiting for the much larger GIF to come over my clogged, slow net connection.
I'd rather not do either of these things, thanks, but OK. (BTW, what
image are you refering to? The types of inlined images which I tend
to consider worthwhile, for now, are those that are smaller as GIFs
than as JPEGs.)
I guess it's not clear what you're advocating, so let me try to break
it down:
- Browsers should support inlined JPEGs.
There are already browsers that do this, so that one was easy.
- Servers should make photographic images available both in JPEG and
GIF format, permitting content-type negotiation to select which.
Sounds reasonable; such is not yet wide-spread. Unfortunately,
there exist browsers which don't work properly for this and would
break.
- Those browsers should be fixed.
Quite reasonable, and much higher in priority than making those
browsers support JPEGs.
William M. Perry
mv> Well, some browsers already support JPEG as inlined images. Some
mv> don't. This discussion, like most discussion of browser
mv> capabilities, seems to be disturbingly Mosaic-centric.
M-x amen :)
[...]
mv> When everyone has 24-bit color and hardware graphics and
mv> floating-point power coming out their nose, inlined JPEGs will be
mv> great. Heck, inlined MPEGs will be great.
Sorry - can't resist. The emacs browser will have inlined mpegs in
the next release if you are using lucid emacs 19.10 or later. :)
-Bill P.