The docs state:
"The TGA and PPM file formats may be used as a storage device for 16 bit
numbers rather than an image file. These formats use the red and green bytes
of each pixel to store the high and low bytes of a height value. "

When I inspect a POV-generated HF_Gray_16 TGA file I find the red channel
all zero, but green and blue channels containing the high order and low
order bytes respectively.

Could it be that the docs differ from the code?

Frans

Post a reply to this message

Could be :)

Sure you didn't start on the wrong byte?  ;-)

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone

Post a reply to this message

F.VERBAAS wrote:
> 
> The docs state:
> "The TGA and PPM file formats may be used as a storage device for 16 bit
> numbers rather than an image file. These formats use the red and green bytes
> of each pixel to store the high and low bytes of a height value. "
> 
> When I inspect a POV-generated HF_Gray_16 TGA file I find the red channel
> all zero, but green and blue channels containing the high order and low
> order bytes respectively.
> 
> Could it be that the docs differ from the code?
> 
> Frans

TGA and BMP have color bytes in BGR order, if I'm not mistaken. I'm not
familiar with the PPM format, but I suspect the same applies. Also, the pixel
order in BMP/TGA is from bottom left to top right.
I'm not sure what header bytes define the file as a HF_16 TGA, possibly a
non-standard number in the color depth byte. Should be quite easy to find out,
if you need it.

Margus

Post a reply to this message

Margus Ramst heeft geschreven in bericht <3708AAEC.44254A54@peak.edu.ee>...

>TGA and BMP have color bytes in BGR order, if I'm not mistaken.

You are perfectly right! I mixed up the sequence for 2 byte entries and
three byte entries. For some reason the HF_Gray_16 format uses three bytes
per pixel.

Thanks for helping me out

Frans

Post a reply to this message

F.VERBAAS wrote in message <370a6ac6.0@news.povray.org>...
>
>You are perfectly right! I mixed up the sequence for 2 byte entries and
>three byte entries. For some reason the HF_Gray_16 format uses three bytes
>per pixel.
>


A fact that leaves me puzzled. Why was the 24 bit TGA format chosen as the
container for 16 bit HF info? 1/3 of the file is in effect wasted space...
Why not use a proprietary format having just 16 bit pixel data? Or even 32
bit, like the Geoforge format.

Margus

Post a reply to this message

ummm, good question... I saw we revamp the format!!! :)

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone

Post a reply to this message

Lance Birch wrote:
> 
> ummm, good question... I saw we revamp the format!!! :)
> 
> --
> Lance.

If it ain't broke don't fix it.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

If it's TOTALLY inefficient... fix it... (sure, it doesn't SOUND catchy...
but it's TRUE)

--
Lance.


---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone

Post a reply to this message

Margus Ramst wrote:
> 
> F.VERBAAS wrote in message <370a6ac6.0@news.povray.org>...
> >
> >You are perfectly right! I mixed up the sequence for 2 byte entries and
> >three byte entries. For some reason the HF_Gray_16 format uses three bytes
> >per pixel.
> >
> 
> A fact that leaves me puzzled. Why was the 24 bit TGA format chosen as the
> container for 16 bit HF info? 1/3 of the file is in effect wasted space...
> Why not use a proprietary format having just 16 bit pixel data? Or even 32
> bit, like the Geoforge format.


A reasonable question, with (I hope) a reasonable answer.

At the time I added 16 bit HF support for TGA images, I wanted to be
able to load the images into viewer programs (this is something like 5-7
years ago and PICLAB, CSHOW, etc were about the best around for use
hobbyists).  16 grey isn't a valid form of TGA file (well, at least it
wasn't considered so by the Truevision engineer I was corresponding with
and no image programs would load it if you put 16 bits into a grey
pixel).  So, I decided that I'd plonk the bits into the red and green
channels of a 24 bit color image.

Note, if you look at the TGA file format specification (yes it is TGA,
not Targa), you could interpret the use of field 3 and field 5.5 to mean
that you can have 16 bit per pixel greyscale images (24 and 32 too). 
Most programs have problems with that.  Just like many programs have a
problem with the use of a non-zero value in field 1.

Xander

Post a reply to this message

Hmm, If it ain't broke, dividee into as many parts as you can, analyse the parts
and try to reassemble it. If you can't reassemble, dive for the backup and
pretend you learned something from the experience. 
usually, you'll have a better view on the thing in hand, knowing at least how to
successfully screw it up, at the best, you can hellply reproduce it, or steal
ideas from it :-)

just a bit of rambling from a fella who learned how to code by taking a demo,
removing all the bright and good things to things he actually understood, then
try to figure out what made their ways better. It usually worked. :-) (yes, I
have an extensive code lib, of originals and my own "degraded" verssions :-)


Ken wrote:
> 
> Lance Birch wrote:
> >
> > ummm, good question... I saw we revamp the format!!! :)
> >
> > --
> > Lance.
> 
> If it ain't broke don't fix it.
> 
> --
> Ken Tyler
> 
> mailto://tylereng@pacbell.net

-- 
//Spider
        [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
                "Marian"
        By: "Sisters Of Mercy"

Post a reply to this message