- From: Ian Tindale <ian_tindale@yahoo.co.uk>
- Date: Thu, 5 Sep 2002 13:03:26 +0100
- To: <www-svg@w3.org>
Not to mention that rasters are largely structureless in terms of differences from one to another (in terms of the actual content of the stored method, ie, it's just series of pixels within compression schemes, and a completely different picture would still result in the same kind of arrangement), apart from the mechanical abstractions of bitplanes and channels etc. One XML-bound raster graphic would appear, from the point of view of its own DOM tree, much like the next, with almost no variation outside of the content, which points to the actual content within the XML structural wrapper as being the vital difference.
Having said that, I've often, since the early PostScript days, pondered on the concept of a sort of 'picture description language' which can break things down to not quite vectors, but generally descriptions of tonal areas and boundaries, able to describe a fully out-of-focus picture and reconstruct it, and basically convey instructions on how to reconstruct the picture or photograph fully, but parametrically.
This isn't quite the same as compression btw, as I envisaged being able to then play with the parameters and dramatically change the nature of the picture in ways that simply aren't possible using present day 'dumb' filters (ie, a photoshop filter generally does things algorithmically, it hasn't a clue what kind of picture it is working on). The semantic problems would be immense (aren't they always) - enough to keep generations of geeks gainfully occupied.
Ian Tindale
> -----Original Message-----
> From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of
> Jon Ferraiolo
> Sent: 28 August 2002 15:17
> To: 'Haeusler Reinhard'; chris@w3.org; www-svg@w3.org
> Subject: RE: Suggestion for a new XML based pixel graphics format, called
> PPG (portable pixel graphics)
>
>
> Richard (and Chris),
> I’ll take a crack at responding to this idea of an XML representation of
> raster graphics.
>
> There are obvious objections to such an idea. Here are a few:
>
> (1) Rasters tend to be very large even when stored in a binary format.
> Expressing them in XML would make them at least an order of magnitude
> larger and slower to parse.
> (2) There are too many raster formats already (PNG, JPEG, JPEG2000,
> TIFF, PSD, WMP, etc.), who needs another
> (3) Rasters are a lot more complicated then they look. You've got issues
> about color spaces, bit depth, pyramidal representations, tiled
> representations, chunky-vs-planar, and alpha compositing, just to rattle
> off a few. Plus lots of metadata issues. JPEG2000 gives a pretty good
> hint as to just how complicated rasters can be.
> (4) There are higher priority things for the W3C to work on.
>
> But approaching this with an open mind, the first question to ask is
> "why?". What benefits would we want to achieve by defining an XML-based
> pixel format?
>
> If you want to manipulate pixels from DOM and scripting, you don't need
> an XML format necessarily -- all you need are DOM APIs to manipulate the
> bits. For example, CSS doesn't have an XML representation but you can
> still manipulate style sheets via scripting using the CSS DOM from DOM
> Level 2.
>
> If you want to embed rasters inline within other XML, you can already do
> this with the 'data:' protocol (http://www.ietf.org/rfc/rfc2397.txt),
> support for which is required in conformant SVG viewers.
>
> During my 10-year tenure at Adobe, I watched Photoshop grow in
> sophistication. Initially, there was only one raster layer in a
> Photoshop file. Now, you have any number of layers, any number of layer
> effects to composite layers together, real vectors and real text. In
> fact, if you look at what the features supported by the market leading
> image editing product, the list of features actually maps pretty closely
> to what SVG supports. So, from one perspective, SVG is already a
> potential candidate for PPG, particularly if DOM APIs were added to
> allow for manipulation of the pixel data.
>
> Just some thoughts.
>
> Jon Ferraiolo
> SVG 1.0 Editor
>
> -----Original Message-----
> From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf
> Of Haeusler Reinhard
> Sent: Monday, August 26, 2002 10:37 PM
> To: 'chris@w3.org'; 'www-svg@w3.org'
> Subject: Suggestion for a new XML based pixel graphics format, called
> PPG (portable pixel graphics)
>
> Sorry - my English is not perfect ... ;-(
> Hello Chris, hello W3 members,
> I like the concept of the various XML based languages, especially the
> vector graphics format SVG ;-)
> But for the pixel graphics there is currently no XML based format
> available (only binary formats, like your PNG or the old GIF).
> So I suggested a concept for such a pixel format, called PPG (portable
> pixel graphics), and I want that to be also an internet standard.
> This, because in XHTML documents everyone could include parts with the
> graphics data in textual form in the document -
> and therefore in the future no one would need to insert references to
> binary picture files in XHTML documents.
> (Exceptions to this are the binary format JPEG for photos of a camera
> and your PNG format for large compressed pixel data.)
> Especially I would not need a tool and file for simple graphics
> elements, like multi-colored points and so on.
> The new format should be interoperable with the already defined standard
> SVG - is a mixed use directly possible ?
> (E.g. a SVG part which refers to - or already contains - a PPG part.) -
> Please give me a hint to this topic - Thanks!
> I want you to add this new format to your Web graphics concept, to have
> the following list of XML graphic standards:
> - XML-based: SVG + PPG
> - compressed-binary: JPEG + PNG
> The MIME type is currently not registered, but it could be like
> "image/ppg" (or similar).
> Please send me your suggestions or requests to the below described
> XML-based pixel graphics format:
> Possibly the name and short hand (or file name extension) is requested
> to be an other one (?)
> Also possibly the structure of the head (info) part and/or the body
> (data) part is requested to be changed generally.
> (E.g. instead of the pixel data storage as 'color layer' it could be
> done as a direct pixel, similarly to the method used in the PNG format.)
> The only things of my suggestion, which should not be changed, are the
> manually (without a tool) writeable format and the XML base of it.
> Also the support for simple transparency (not variable translucency)
> should be a part of this format.
> The new pixel graphics format should be the low end graphics format for
> simplest usage on Web pages - e.g. for multi-colored points.
> Here is now my suggestion and I am looking forward to get your response
> to this concept.
> --> Many thanks in advance!
> Best regards, Reinhard Häusler
> mailto:reinhard.haeusler@siemens.com
> ---
> ----------------------------------------------------
> PPG ... Portable-Pixel-Graphics
> ----------------------------------------------------
> Properties:
> The format is XML-based - it should be defined via an DTD or an XML
> schema - to be done ;-)
> It supports transparent graphics parts, like the old GIF format.
> Picture data structure:
> - Structure of a whole picture: Every so called 'color layer' of the
> whole graphics is stored in one element, called layer.
> Every layer contains data in the structure: outer for vertical
> sequence - and inner for horizontal sequence.
> - Horizontal picture layer structure: Every byte, as sequence of 8
> bits represents 8 pixels (horizontal side by side).
> - Vertical picture layer structure: Every line (with horizontal
> structure) follows side by side the other one.
> Possible there is an better word instead of layer (could be also used
> for the XML tag) ... :-)
> General structure of the pixel graphics format:
> - info part with a data type information (and possible with an to the
> XML head part additional semantic version information)
> - data part with a color palette (with 'transparent' information) and
> the so called 'layer list' (with the pixel informations).
> Details of the pixel graphics format:
> The mandatory type information contains a slash ('/') separated word of
> the format "PPG/<x-pix>x<y-pix>/<bit-depth>",
> which means a pixel graphics picture with horizontal <x-pix> pixels,
> vertical <y-pix> pixels and color depth of <bit-depth> bits.
> The optional version information holds a simple version string.
> The mandatory color palette consists of the color definitions (using the
> usual HTML 'rgb'-format in textual form - e.g. '#00FF00') and
> the only one transparent definition for one of in this color palette
> defined colors.
> The mandatory layer list consists of a sequence of layer definitions
> (using a similar hexadecimal textual form - without the char '#').
> Every layer definition consists of a sequence of logical lines, which
> themselves consists of a sequence of bytes.
> Simple example:
> PPG definition for a small pixel graphic (16 x 16 pixels) with 4 colors.
>
> Done in two syntax variants ... :-)
> Remark: Currently there is only this example to 'define' the used XML
> tags - DTD or XML schema definition for it is to be done!
> <?xml version="1.0" encoding="ISO8859-1" ?>
> <!-- Example_small.PPG -->
> <!-- ================= -->
> <!-- Simple Example of a PPG (portable pixel graphics) format file
> -->
> <!-- Reinhard Häusler -->
> <!-- Date: 2002-08-26 -->
> <!-- ************* -->
> <!-- XML like head --> <!-- to be defined - reference to DTD or XML
> schema -->
> <!-- ************* -->
> <ppg>
> <info><!-- info part (instead of head) -->
> <type>PPG/16x16/2</type><!-- this means: 16 (horizontal) x 16
> (vertical) pixels and 2 bit color depth -->
> <version>0.0.1</version><!-- no valid version available now - only
> a suggestion for working -->
> </info>
> <data><!-- data part (instead of body) -->
> <palette><!-- list of the color definitions and the one
> transparent definition -->
> <!-- explanation for 'bit sequence': 'ab' means layer 0 is 'a'
> and layer 1 is 'b' -->
> <color num="0">#000000</color><!-- 0 means the bit sequence '00'
> --><!-- black -->
> <color num="1">#007700</color><!-- 1 means the bit sequence '01'
> -->
> <color num="2">#007700</color><!-- 2 means the bit sequence '10'
> -->
> <color num="3">#00FF00</color><!-- 3 means the bit sequence '11'
> --><!-- green -->
> <transparent="0" /><!-- this means: color with num="0" is
> transparent -->
> <!-- (it could also be empty for no
> transparent color) -->
> </palette>
> <layers><!-- list of layer definitions -->
> <layer num="0"><!-- list of pixel lines of layer 0 -->
> <b>0FF0</b><b>1FF8</b><b>1FF8</b><b>3FFC</b><!-- byte-sequences
> 1 to 4 (of layer 0) -->
> <b>3FFC</b><b>7FFE</b><b>7FFE</b><b>FFFF</b><!-- byte-sequences
> 5 to 8 (of layer 0) -->
> <b>FFFF</b><b>7FFE</b><b>7FFE</b><b>3FFC</b><!-- byte-sequences
> 9 to 12 (of layer 0) -->
> <b>3FFC</b><b>1FF8</b><b>1FF8</b><b>0FF0</b><!-- byte-sequences
> 13 to 16 (of layer 0) -->
> </layer>
> <layer num="1"><!-- list of pixel lines of layer 1 -->
> <b>0000</b><b>0000</b><b>0FF0</b><b>1FF8</b><!-- byte-sequences
> 1 to 4 (of layer 1) -->
> <b>1FF8</b><b>3FFC</b><b>3FFC</b><b>7FFE</b><!-- byte-sequences
> 5 to 8 (of layer 1) -->
> <b>7FFE</b><b>3FFC</b><b>3FFC</b><b>1FF8</b><!-- byte-sequences
> 9 to 12 (of layer 1) -->
> <b>1FF8</b><b>0FF0</b><b>0000</b><b>0000</b><!-- byte-sequences
> 13 to 16 (of layer 1) -->
> </layer>
> </layers>
> </data>
> </ppg>
> <!-- (C) Reinhard Häusler 2002 -->
> A nearly shortest variant of this definition (if the concept above would
> generate too much overhead) is shown below - but this is more difficult
> to read ;-(
> <?xml version="1.0" encoding="ISO8859-1" ?>
> <!-- Example_min.PPG -->
> <!-- =============== -->
> <!-- Reinhard Häusler -->
> <!-- Date: 2002-08-26 -->
> <ppg>
> <i><!-- info -->
> <t>PPG/16x16/2</t><!-- type -->
> <v>0.0.1</v><!-- version -->
> </i>
> <d><!-- data -->
> <cp><!-- color-palette -->
> <c n="0">#000000</c><!-- color 0 -->
> <c n="1">#007700</c><!-- color 1 -->
> <c n="2">#007700</c><!-- color 2 -->
> <c n="3">#00FF00</c><!-- color 3 -->
> <t="0" /><!-- transparent -->
> </cp>
> <ll><!-- layer-list -->
> <l n="0"><!-- layer 0 -->
> 0FF0,1FF8,1FF8,3FFC,<!-- byte-sequences 1 to 4 (of layer 0)
> -->
> 3FFC,7FFE,7FFE,FFFF,<!-- byte-sequences 5 to 8 (of layer 0)
> -->
> FFFF,7FFE,7FFE,3FFC,<!-- byte-sequences 9 to 12 (of layer 0)
> -->
> 3FFC,1FF8,1FF8,0FF0 <!-- byte-sequences 13 to 16 (of layer 0)
> -->
> </l>
> <l n="1"><!-- layer 1 -->
> 0000,0000,0FF0,1FF8,<!-- byte-sequences 1 to 4 (of layer 1)
> -->
> 1FF8,3FFC,3FFC,7FFE,<!-- byte-sequences 5 to 8 (of layer 1)
> -->
> 7FFE,3FFC,3FFC,1FF8,<!-- byte-sequences 9 to 12 (of layer 1)
> -->
> 1FF8,0FF0,0000,0000 <!-- byte-sequences 13 to 16 (of layer 1)
> -->
> </l>
> </ll>
> </d>
> </ppg>
> Many combinations of this two concept versions or even other
> implementations are possible.
> --> Please make your suggestions to this syntax and/or semantics ....
> :-)
>
> Reinhard Häusler (mailto:reinhard.haeusler@siemens.com) - 2002-08-26
Received on Thursday, 5 September 2002 08:03:44 UTC