This repository has been archived on 2024-04-08. You can view files and clone it, but cannot push or open issues or pull requests.
phptsmadmin/includes/jpgraph/docs/chunkhtml/ch05s02.html
2011-05-28 19:51:52 +10:00

50 lines
5.7 KiB
HTML
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>What is an image?</title><link rel="stylesheet" type="text/css" href="manual.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.0"><link rel="home" href="index.html" title="JpGraph Manual"><link rel="up" href="ch05.html" title="Chapter 5. Fundamentals of dynamic graph generation"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">What is an image?</th></tr><tr><td width="20%" align="left"> </td><th width="60%" align="center">Chapter 5. Fundamentals of dynamic graph generation</th><td width="20%" align="right"> </td></tr></table><hr></div><div class="sect1" title="What is an image?"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2494175"></a>What is an image?</h2></div></div></div>
<p>This might be strange question and you might already now the answer but having a
true understanding will help. An image is simply a data stream of octets (bytes)
specifying the exact color of a number of pixels. A typical image uses 32 bits to
specify the color which means it can encode 2^32 different colors (Homework: How
many gray levels is possible with 32 bits?). It would be perfectly possible to send
this data stream as it is and indeed this is how the bitmap (BMP) format specifies
the data. However, image data usually have a lot of redundancies that can be used to
reduce the size of the data that needs to be transmitted to specify any given image.
These compression formats are what is more commonly known as for example PNG, JPEG
or GIF type of images. So it is actually more correct, in our view, to look upon
these formats as different compression techniques rather than as true image formats. </p>
<p>Contrary to popular belief it is not the suffix on a file per se that identifies a
particular file as an image on a HTTP server but rather the mapping on the server
that instructs the server to send back a particular header for a particular file
type (as identified by the file suffix), the MIME type. This might not seem like an
important distinction to make but keeping this in mind will help understanding how
images are created with a PHP script.</p>
<p>A normal PHP scripts sends back character data (or more likely HTML encoded
character data) that is displayed by the browser. However it is nothing that stops
the PHP script from sending back data that instead should be interpreted as an image
assuming of course we know how to create such data.. </p>
<p>How the client (i.e. the browser) should interpret the data sent is all controlled
by the header that is sent before the data. So this now leads us to the idea that if
our PHP script by some means constructs a valid image, compressed in a known format
(say PNG), we can tell the client to interpret the data we send back as an image by
just making sure we first send a header indicating that the data is an image.</p>
<p>This could now lead us to the perhaps surprising but crucial insight that if we
call our script that sends back valid image data "<code class="filename">myimage.php</code>"
and open it in a browser, for example by opening the local URI
"<code class="filename">http://localhost/myimage.php</code>" for the browser this is no
different then opening an image directly (for example
"<code class="filename">http://localhost/myimage.png</code>") </p>
<p>The only difference is that in the first case (our PHP script) we create the
header and data our self and in the second case the HTTP server looks up the file
suffix (*.png) to find out what kind of header to send before reading the file and
just passing on the data to the client.</p>
<p>Armed with this new knowledge we realize that our PHP script <span class="italic">is</span> an image for all practical purposes and intent from
a clients point of view. So we could safely name our PHP script as a target for an
<span class="markup">&lt;img&gt;</span> tag. This gives us the final and most common way to
call a graph script in a HTML page. </p>
<p><code class="code">&lt;img src="myimage.php"&gt;</code></p>
<p>in exactly the same way as we would do with the old type of images. The "*.php"
suffix is no problem since the client (e.g. the browser) don't care what the file
ending is. It only cares about what header the server returns. If that header tells
the browser that the data received should be interpreted as a PNG image it will do
so regardless of the name of the source file on the server.</p>
</div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"> </td><td width="20%" align="center"><a accesskey="u" href="ch05.html">Up</a></td><td width="40%" align="right"> </td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>