Image Slicing was Re: [oclug]for the mac / linux fans

[Brad Barnett]

On 14 Jan 2003 03:15:16 -0500
Shad Young <shad.young at sympatico.ca> wrote:

> On Tue, 2003-01-14 at 03:05, Shad Young wrote:
> > On Tue, 2003-01-14 at 02:42, Shad Young wrote:
> > > On Tue, 2003-01-14 at 01:46, Brad Barnett wrote:
> > > 
> > > 
> > > > 
> > > > [endbit.jpg][endbit.jpg][endbit.jpg]  
> > > > [endbit.jpg][endbit.jpg][endbit.jpg]
> > > > [endbit.jpg][endbit.jpg][endbit.jpg] <bigmiddlepart>
> > > > <clone_of_left_side>[endbit.jpg][endbit.jpg][endbit.jpg]
> > > > [endbit.jpg][endbit.jpg][endbit.jpg]
> > > > [endbit.jpg][endbit.jpg][endbit.jpg]
> > > > 
> > > > Wow!  Suddenly you've saved tons upon tons of filesize, right! 
> > > > Let's look at this in more detail!  Instead of one image, you have
> > > > one center part, but the red ends have been chopped into 36
> > > > identical pieces, which only needs to be fetched from the server
> > > > once!  A savings?
> > > > 
> > > > Take a look at this image of the Canadian flag:
> > > > 
> > > > http://canflag.ptbcanadian.com/images/regular/311x150.jpg
> > > > 
> > > > -rw-r--r--    1 bbarnett bbarnett     4178 Jan 12 23:02
> > > > 311x150.jpg
> > > > 
> > > > Now, using XV, I will take it, and crop a piece of the red ends,
> > > > equal to 1/18th of the size.  This means that each end will
> > > > represet the same as above.  Look however!  Part a is the small
> > > > end bit that will be repeated, and part b is the middle "leaf"
> > > > part of our flag.
> > > > 
> > > > -rw-r--r--    1 bbarnett bbarnett      743 Jan 12 23:10
> > > > 311x150_a.jpg-rw-r--r--    1 bbarnett bbarnett     3224 Jan 12
> > > > 23:11 311x150_b.jpg
> > > > 
> > > > -----------------------------------------------------------------
> > > > ---
> > > > 
> > > > How do you find it difficult to understand that 3224+743= 3967,
> > > > while the original image was 4178 bytes?  How do you find it
> > > > difficult to understand, that the actual GET statement (with full
> > > > path) to the web server, the extra IMG SRC and what not, actually
> > > > makes the above spliced image MORE costly for bandwidth? 
> > > > Repeating a red square 18 times per end, for a total of 36 times,
> > > > doesn't save anything.  It costs you in terms of bandwidth, file
> > > > handles on the server, and cpu usage on the client.
> > > 
> > > 
> > > Wow all that and you still fail to understand that the rest of the
> > > image is built out of cache and that the browser will not actually
> > > send a get request for ever single img tag? I already admitted that
> > > memory usage is increased, but that is client side and of minor
> > > consequence as bandwidth is far more costly.

David and others on this list are quite right to ignore your posts, Shad. 
I was polite enough to actually get dragged into a conversation with you
again, and the end result is simply not worth it.  Even with information
in a post to refute what you are saying, you chose not to read it.  I'll
try one more time to explain things to you.

Take paragraph number one of your three reply, bandwidth wasting response.
 What you say is clearly not the case, as is shown in my previous email. 
Of course, you chose to cut out that part, the part that states:

"Wow Shad, that's a total of .. well, let's just call it 80 chars * 8
lines, or 640 bytes.  So, instead of one large image, of 4178 bytes, we
have two images.  The second is loaded 36 times instead of being part of
the original, so we need 36 extra IMG SRC tags.  We also need two GET
requests to the server instead of one, so add 640 bytes for the second
one."

The above clearly states that my calculations are based on two GET
requests from the server, not 37.  For some odd reason, even though I've
mentioned it more than three other times during my post to you, you still
think this is based on multiple GET requests for each copy of the 36
images.  Please pay attention.  The intelligence you save may be your own.

> > 
> > And let me add to this that you are working with an image that doesn't
> > necessarily work well, but say said image was 24bit and more than 25k
> > in size... if you strip out blocks of solid and use sizing and image
> > arrays then the savings becomes more observable, and the savings
> > increases in proportion to image density and layout complexity. Like I
> > said, you seem to have chosen to ignore some of the basics and are
> > locking your entire argument down based on one example. Not good
> > science.

Actually, Shad, my other posts experiment with just what you've said
above.  Of course, like the very post you are replying to, you failed to
read them fully as well.  

> 
> And let me further add that nobody who knows anything about web
> development is going to take the time to slice up a 4k image for any
> reason other than functional necessity. Nobody.
> 
> 

Ah, but that's the problem, Shad.  Let me give you a few hints:

1) before replying to a post, read it.  Honestly, truly read it.  That way
you won't fire off three replies to a single post someone makes. 
Obviously you aren't reading the entire post, or you wouldn't be doing
things like you do in paragraph one of your three post reply.  I used to
be fairly hasty with replies too, at one time.  A good rule of thumb is to
wait 20 minutes after you read a message, if you want to honestly
contribute to the discussion.  This way, your subconscious has time to
peculate over the ideas presented in the email.  This not only improves
the discussion on both sides, but it reduces flamage, which you should be
happy of right about now ;)     

2) During this entire series of posts I have made, I have stated that
slicing needs to be used correctly.  I've seen cases where people HAVE cut
up 4k images, for no other reason than to try to save bandwidth!  I've
even mentioned this multiple times, and that this is my pet peeve.  They
just don't get the numbers.  They think that if they save 30 bytes somehow
in image size, that they are saving bandwidth, but they ignore the 2000
bytes of extra bandwidth needed to accommodate this behaviour.  

3) another hint is that you seem to be arguing with me over something I
agree upon.  I've clearly shown in other posts that sure, if you have a
40k image, yes.. you can save 1000 or so bytes by slicing.  However, my
examples show large, massive banners of red on either side of a hi-res
image.  This is the best case scenario.  Smaller banners or banners of two
different colours on each side would remove any advantage you might have
in this case.

4) a good rule of thumb is this.  If you are trying to save bandwidth
through slicing, add an extra 2000 bytes for the extra HTML and GET query
to the server.  If you don't save 2000 bytes in your slicing, it's just
not even worth it!  You'll lose!  Anything under 20k is a loss, anything
under 40k to 60k is very questionable!  There are cases where a 40k image
would slice up nicely, but unless you realise that it will take an extra
2k because of this behaviour, you may lose in the end

5) again, Shad, what you don't seem to be realising is that these series
of posts have been written to show that slicing can be misused.  Do you
contest that?  If not, then just why are you replying to them, yelling
about how I am wrong?  I have worked with web designers, graduates, on
more than one occasion that sliced up images to save a few bytes, and
didn't take into account the extra HTML and negotiation as well.

6) Something that hasn't even entered into this equation is the cost of
bandwidth versus the cost of manpower.  Some of these people also worked
on low bandwidth sites!  Imagine, if you will, someone taking an extra 4
hours to slice up multiple images on a series of pages and working it into
the html, for a saving totaling say 10k.  Let's make it very, very
favourable, and say it is 100k. 
	Assumptions: 
		- every visitor views all the images
		- The employee is paid $40 per hour
		- bandwidth costs $5 per gig

	You would need over 10000 hits, with people viewing every image, in order
to generate $5 worth of bandwidth (we're not talking gibibytes, but
gigabytes of bandwidth, people ;).  That means we'd need 320000 hits,
_just_ to break even.  Naturally this is very conservative, since usually
every visitor does not view every graphic on this site.

So, in a low bandwidth / slower site, this sort of thing is definitely a
loss!  However, I've seen people use this method to "save" bandwidth, on
tiny, private sites, that get 1000 hits per month!

7) the lesson in all of these posts has clearly been this.  Slicing to
save bandwidth can work, but TAKE INTO ACCOUNT THE EXTRAS!  It's not all
about the byte count when you do an "ls" on those files people!  Many
Ottawa schools, however, teach only "ls", and not the extra encumbrances!