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 Wednesday, 28 August 2002 10:17:40 UTC