On 6/4/2012 12:59 PM, Miles Fidelman wrote:
BGB wrote:
On 6/4/2012 6:48 AM, Miles Fidelman wrote:
BGB wrote:
and, recently devised a hack for creating "component layered JPEG
images", or, basically, a hack to allow creating JPEGs which also
contained alpha-blending, normal maps, specular maps, and luma
maps (as an essentially 16-component JPEG image composed of
multiple component layers, with individual JPEG images placed
end-to-end with marker tags between them to mark each layer).
dunno if anyone would find any of this all that interesting though.
well, I'd certainly be interested in seeing that hack!
Mile Fidelman
from a comment in my JPEG code:
<--
BGB Extensions:
APP11: BGBTech Tag
ASCIZ TagName
Tag-specific data until next marker.
<snip>
Pardon my cluelessness here, but what exactly are you showing as
"JPEG code?" Is this part of a JPEG file header, part of code that's
generating a JPEG file, what?
the "JPEG code" reference was, basically, to my JPEG encoder/decoder
(which implements ITU T.81 and JFIF), and is written in C.
the design shouldn't be too hard to retrofit onto a "standard" encoder
though (such as "libjpeg"), given it doesn't significantly alter the
file-format, but as-is I use my own JPEG implementation.
in this case, basically it is implemented as wrapper functions, which
essentially just daisy-chain to the normal JPEG encoder/decoder
functions.
but, anyways, to try to explain the JPEG format:
basically, it consists mostly of "marker tags", defined as byte values.
there is no particular "file header" in JPEG, only marker tags, and
data which follows tags, and the relative positioning and ordering of
these marker tags.
the byte value 0xFF is "magic" in JPEG, and serves to escape various
tags (given in the following byte). it may not be used directly as a
data value in encoded data (it needs to be escaped).
for example, "0xFF, 0x00" escapes an 0xFF byte.
so, a few major tags.
SOI (Start Of Image, 0xD8) and EOI (Start Of Image, 0xD9) are also
major, as these mark the start and end of an encoded image (all other
image-encoding markers exist between these tags).
DHT (Define Huffman Table, 0xC4), defines the Huffman table.
DQT (Define Quantization Table, 0xDB), defines the Huffman table.
SOF0 (Start Of Frame 0, 0xC0), defines the resolution and, components,
and sub-sampling of the image (for color images, always 3 components
and 4:2:0 in JFIF, and the color-space is always YUV / YCbCr).
SOS (Start Of Scan, 0xDA), marks the start of the compressed image data.
and, in this case:
APP0-APP15 (0xE0-0xEF), which define application-specific extension tags.
these are commonly used to encode various extensions features. if a
codec sees one it doesn't recognize, it will typically skip over it
(skip until the next marker tag).
APP0 is used by JFIF, and APP1 and APP2 are used by EXIF.
APP3-APP15 are used by various other people for various extensions.
I ended up using APP11 because, AFAICT, no one else was using it.
the usual convention for using these tags is to have them followed by
an ASCIIZ string, which is what I was doing. I also ended up also
using an ASCIIZ string to encode parameters as well.
but, all this means that the layer tag will come before the SOI tag.
so, for example (leaving out 0x prefixes):
FF, E0, xx, xx, "JFIF", 00, ..., //JFIF "header" (often optional)
FF, EB, "CompLayer", 00, "RGB", 00, //layer marker
FF, D8, ..., FF, D9, //encoded image
FF, EB, "CompLayer", 00, "XYZ", 00,
FF, D8, ..., FF, D9, //encoded image
...
And... I don't suppose you have any examples of such files - either
behind URLs, or for download?
sadly, not as of yet.
I only recently implemented it, and it is mostly intended for AVI
videos (I don't currently use it for textures, which typically give
all this information as multiple image files).
given the way AVI works, there would be no good way to use multiple
images per frame in an AVI (thus, the major reason for creating this).
(note: OpenDML specifies something similar already for encoding
interlaced MJPEG videos).
even if files were available though, most likely only the basic RGB
image would be visible to existing applications (the other layers
would be ignored).
Thanks,
Miles
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
