RSS News Feed

Re New free source image processing code

Message-ID:<Lo0sm.66103$Y83.36688@newsfe21.iad>
Subject:

Re: New free source image processing code

Date:Wed, 16 Sep 2009 08:24:29 +0100

Martin Leese wrote:
> aruzinsky wrote:
> 
>> On http://telin.ugent.be/~frooms/friep/screenshots/ you are using full
>> sized PNG files of approximately 1 MB each as THUMBNAILS!  That is
>> grossly inconsiderate of people with dial up modems.  Width or height
>> specifiers should almost never be used in <img> tags.  For thumbnails,
>> you should resize the images and save as JPEG.
> 
> I agree that large images on a Web page
> are inconsiderate (I, too, am on dial-up),
> however, width and height attributes should
> *always* be used.

Dialup is getting a lot rarer now though. Increasingly you see 
commercial websites with such excessive and gross Shockwave animations 
that it takes an appreciable time to get going even on fast broadband.
> 
> If width and height attributes are not used,
> the browser will pause until the image has
> been downloaded before displaying the rest
> of the page.  With width and height the
> browser leaves a gap, which is filled in
> later, and continues displaying the page.
> I make thumbnails of the actual size I want
> to display, and then specify this in the
> width and height.
> 
> Whether JPEG or PNG should be used depends
> on which one compresses better.  This
> depends on the image content, particularly
> on the noise level.  However, I agree most
> of the screenshots displayed would almost
> certainly compress better with JPEG than
> PNG.

One of the irritating things about the JPEG standard is that for 
thumbnails a large proportion of the data transferred is actually 
identical generic header material containing Huffman and quantisation 
tables (where most applications use the accidentally defined defaults 
taken from the examples in the original standards document). Hardware 
guys resisted having the JPEG spec start out with a predefined internal 
state or a scaling rule for the default quantisation tables. They never 
envisioned this use for small images where it matters.

JPEGs still tend to be smaller than most alternatives except for 
material with a severely reduced colour palette. And even then they can 
be competitive with custom quantisation tables.

BTW I agree it is antisocial to use large images scaled down by the 
WIDTH & HEIGHT specifiers, but that the specifiers should be used to 
allow the page to render immediately with placeholders.

It is also kinder to save JPEGs for the web using the progressive 
iterative refinement so that a rough image can be rendered quickly 
rather than a slow paint from the top at full resolution. Progressive 
JPEGs are often marginally smaller for larger images (but it isn't the 
default save mode in many apps).

Regards,
Martin Brown

Message-ID:<7e3a1b1f-2b7f-4d8c-b5a5-f651744b64a3@33g2000vbe.googlegroups.com>
Subject:

Re: New free source image processing code

Date:Wed, 16 Sep 2009 16:03:51 +0100

On Sep 16, 1:24=A0am, Martin Brown <|||newspam...@nezumi.demon.co.uk>
wrote:
> ...
> It is also kinder to save JPEGs for the web using the progressive
> iterative refinement so that a rough image can be rendered quickly
> rather than a slow paint from the top at full resolution.

No, no, no.  The person who invented that deserves to go to Hell.  If
an image looks like crap, I do not sit still, like a fool, hoping that
it will get better with time.  Instead, I move on, usually to another
web page.  I like progressive rendering because the image is its own
progress bar.

Message-ID:<4x7sm.34739$nP6.6146@newsfe25.iad>
Subject:

Re: New free source image processing code

Date:Wed, 16 Sep 2009 16:31:13 +0100

aruzinsky wrote:
> On Sep 16, 1:24 am, Martin Brown <|||newspam...@nezumi.demon.co.uk>
> wrote:
>> ...
>> It is also kinder to save JPEGs for the web using the progressive
>> iterative refinement so that a rough image can be rendered quickly
>> rather than a slow paint from the top at full resolution.
> 
> 
> No, no, no.  The person who invented that deserves to go to Hell.  If

A very strange viewpoint for someone on a limited bandwidth connection. 
A rough outline in blocks that appear quickly (typically 2% of total 
time) and then get progressively smaller is useful a lot sooner.

> an image looks like crap, I do not sit still, like a fool, hoping that
> it will get better with time.  Instead, I move on, usually to another
> web page.  I like progressive rendering because the image is its own
> progress bar.

And so it is with iterative JPEG if you are on a slow enough connection 
to actually see the difference. The waves of successive higher frequency 
updates are visible if you look carefully. The iterative compressed JPEG 
file is marginally more compact for most source material too.

Regards,
Martin Brown

Message-ID:<7645cabf-38fd-481e-a782-c90ddeb537f5@z28g2000vbl.googlegroups.com>
Subject:

Re: New free source image processing code

Date:Wed, 16 Sep 2009 17:07:46 +0100

On Sep 16, 9:31=A0am, Martin Brown <|||newspam...@nezumi.demon.co.uk>
wrote:
> aruzinsky wrote:
> > On Sep 16, 1:24 am, Martin Brown <|||newspam...@nezumi.demon.co.uk>
> > wrote:
> >> ...
> >> It is also kinder to save JPEGs for the web using the progressive
> >> iterative refinement so that a rough image can be rendered quickly
> >> rather than a slow paint from the top at full resolution.
>
> > No, no, no. =A0The person who invented that deserves to go to Hell. =A0=
If
>
> A very strange viewpoint for someone on a limited bandwidth connection.
> A rough outline in blocks that appear quickly (typically 2% of total
> time) and then get progressively smaller is useful a lot sooner.
>
> > an image looks like crap, I do not sit still, like a fool, hoping that
> > it will get better with time. =A0Instead, I move on, usually to another
> > web page. =A0I like progressive rendering because the image is its own
> > progress bar.
>
> And so it is with iterative JPEG if you are on a slow enough connection
> to actually see the difference. The waves of successive higher frequency
> updates are visible if you look carefully. The iterative compressed JPEG
> file is marginally more compact for most source material too.
>
> Regards,
> Martin Brown

No, the top down rendering kind lets me know when an image is fully
rendered and I can usually determine whether I want to see the
download completed when the file is 1/3 downloaded.   If the top 1/3
looks like something that doesn't interest me, I move on.  However, I
must say that it would be better if displayed from bottom up, because
the top of an image is often sky and you cannot determine much from
sky.   I have seen plenty of

1. abstract art images

2. images enlarged by width and height specifiers

that look like iteratively rendered JPEG before completion and they
are too easily confused.  Like I said before, I am not going to be
suckered into waiting for a bad image to improve with time.

Furthermore, with my IE web browser, some image downloads stop before
the file is completely downloaded and just pressing the refresh button
doesn't help.  With iterative refinement formats, I have no way to
tell that this happened.

Message-ID:<d5d6dbe5-85f5-417f-ad9c-e7e15e51457e@b18g2000vbl.googlegroups.com>
Subject:

Re: New free source image processing code

Date:Wed, 16 Sep 2009 16:31:55 +0100



> > I agree that large images on a Web page
> > are inconsiderate (I, too, am on dial-up),
>
> BTW I agree it is antisocial to use large images scaled down by the
> WIDTH & HEIGHT specifiers,

Sorry for being an inconsiderate and antisocial person...

Page has now thumbs that are really separate scaled-down jpg's.

No offence meant: I was so used to use broadband at work and at home
that I forgot to consider people with other connection types: it was
just a
very quickly built page with images generated on the fly with my
software and
put as is on the page (which was also written on the fly just using
plain
simple HTML)...

Regards,

Filip

Message-ID:<07af7a7e-cf9b-40e5-a6d7-123c5ab379eb@o36g2000vbl.googlegroups.com>
Subject:

Re: New free source image processing code

Date:Wed, 16 Sep 2009 15:52:31 +0100


On Sep 15, 7:17=A0pm, Martin Leese <ple...@see.Web.for.e-mail.INVALID>
wrote:
> aruzinsky wrote:
> > Onhttp://telin.ugent.be/~frooms/friep/screenshots/you are using full
> > sized PNG files of approximately 1 MB each as THUMBNAILS! =A0That is
> > grossly inconsiderate of people with dial up modems. =A0Width or height
> > specifiers should almost never be used in <img> tags. =A0For thumbnails=
,
> > you should resize the images and save as JPEG.
>
> I agree that large images on a Web page
> are inconsiderate (I, too, am on dial-up),
> however, width and height attributes should
> *always* be used.
>
> If width and height attributes are not used,
> the browser will pause until the image has
> been downloaded before displaying the rest
> of the page. =A0With width and height the
> browser leaves a gap, which is filled in
> later, and continues displaying the page.
> I make thumbnails of the actual size I want
> to display, and then specify this in the
> width and height.
>
> Whether JPEG or PNG should be used depends
> on which one compresses better. =A0This
> depends on the image content, particularly
> on the noise level. =A0However, I agree most
> of the screenshots displayed would almost
> certainly compress better with JPEG than
> PNG.
>
> --
> Regards,
> Martin Leese
> E-mail: ple...@see.Web.for.e-mail.INVALID
> Web:http://members.tripod.com/martin_leese/

You mean that the rest of the page will display out of place until the
images are downloaded which is a good point.  The OP only used height
specifiers, so I guess it should be, "width or height."

There is a better reason to not resize an image display with HTML
height or with specifiers.  The interpolation done by most browsers is
very bad.  I suspect that most PC browsers use the Microsoft SDK for
resizing, something like CDC::SetStretchBltMode followed by
CImage::StretchBlt.

Message-ID:<uq7sm.45244$PH1.39189@edtnps82>
Subject:

Re: New free source image processing code

Date:Wed, 16 Sep 2009 16:24:10 +0100


aruzinsky wrote:

> On Sep 15, 7:17 pm, Martin Leese <ple...@see.Web.for.e-mail.INVALID>
> wrote:
>> If width and height attributes are not used,
>> the browser will pause until the image has
>> been downloaded before displaying the rest
>> of the page.  With width and height the
>> browser leaves a gap, which is filled in
>> later, and continues displaying the page.

> You mean that the rest of the page will display out of place until the
> images are downloaded which is a good point.  The OP only used height
> specifiers, so I guess it should be, "width or height."

No, not out of place; the rest of the page
will not display at all.

 From the HTML 4.01 standard at:
http://www.w3.org/TR/html401/struct/objects.html#h-13.7.1

"The height and width attributes give user
agents an idea of the size of an image or
object so that they may reserve space for it
and continue rendering the document while
waiting for the image data."

Browsers are free to implement other
behaviour, but in my experience they don't.

-- 
Regards,
Martin Leese
E-mail: please@see.Web.for.e-mail.INVALID
Web: http://members.tripod.com/martin_leese/

Message-ID:<ff592579-e535-429a-8708-891f4bf2a6c4@31g2000vbf.googlegroups.com>
Subject:

Re: New free source image processing code

Date:Wed, 16 Sep 2009 16:38:51 +0100


On Sep 16, 9:24=A0am, Martin Leese <ple...@see.Web.for.e-mail.INVALID>
wrote:
> aruzinsky wrote:
> > On Sep 15, 7:17 pm, Martin Leese <ple...@see.Web.for.e-mail.INVALID>
> > wrote:
> >> If width and height attributes are not used,
> >> the browser will pause until the image has
> >> been downloaded before displaying the rest
> >> of the page. =A0With width and height the
> >> browser leaves a gap, which is filled in
> >> later, and continues displaying the page.
> > You mean that the rest of the page will display out of place until the
> > images are downloaded which is a good point. =A0The OP only used height
> > specifiers, so I guess it should be, "width or height."
>
> No, not out of place; the rest of the page
> will not display at all.
>
> =A0From the HTML 4.01 standard at:http://www.w3.org/TR/html401/struct/obj=
ects.html#h-13.7.1
>
> "The height and width attributes give user
> agents an idea of the size of an image or
> object so that they may reserve space for it
> and continue rendering the document while
> waiting for the image data."
>
> Browsers are free to implement other
> behaviour, but in my experience they don't.
>
> --
> Regards,
> Martin Leese
> E-mail: ple...@see.Web.for.e-mail.INVALID
> Web:http://members.tripod.com/martin_leese/

I have seen thousands of web pages with all text fully displayed below
images as they are being downloaded and rendered without Height and
Width specifiers.  In fact, I have written such a web page here:
http://www.general-cathexis.com/interpolation/index.html