 |
|
|
|
|
|
| |
| |
|
|
From: Margus Ramst
Subject: Re: TGA files containing HF_Gray_16 data, Question 2
Date: 6 Apr 1999 20:14:15
Message: <370a9547.0@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Lance Birch
Subject: Re: TGA files containing HF_Gray_16 data, Question 2
Date: 7 Apr 1999 02:49:57
Message: <370af205.0@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Lance Birch
Subject: Re: TGA files containing HF_Gray_16 data, Question 2
Date: 7 Apr 1999 04:10:42
Message: <370b04f2.0@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Alexander Enzmann
Subject: Re: TGA files containing HF_Gray_16 data, Question 2
Date: 7 Apr 1999 11:50:03
Message: <370B70E4.519236CB@mitre.org>
|
|
|
| |
| |
|
|
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] bahnhof se ]-[ 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
|
|
| |
| |
|
|
From: Lance Birch
Subject: Re: TGA files containing HF_Gray_16 data, Question 2
Date: 7 Apr 1999 20:58:12
Message: <370bf114.0@news.povray.org>
|
|
|
| |
| |
|
|
Huh? What do you mean it isn't Targa? I thought that TGA was just a
shortened version... and that the file format was called Truevision's
Targa... Or am I totally missing the mark here? And if so, what is Targa
and why do all Targa streaming video output boards stream TGAs if they
aren't Targas?
Now I'm totally confused...
--
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:
>
> Huh? What do you mean it isn't Targa? I thought that TGA was just a
> shortened version... and that the file format was called Truevision's
> Targa... Or am I totally missing the mark here? And if so, what is Targa
> and why do all Targa streaming video output boards stream TGAs if they
> aren't Targas?
>
> Now I'm totally confused...
>
> --
> Lance.
Please look at the graphics file formats page for the answer
to his compelling mystery. The TGA specification is incorrectly
referred to as the targa file format and this mistake is repeated
on a very large scale in the graphics industry and by arm chair
graphics format expert wanna bees (which includes most of the
computer users who use any type of graphics program).
http://www.dcs.ed.ac.uk/~mxr/gfx/
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
From: Lance Birch
Subject: Re: TGA files containing HF_Gray_16 data, Question 2
Date: 7 Apr 1999 21:22:23
Message: <370bf6bf.0@news.povray.org>
|
|
|
| |
| |
|
|
THANKS! Now I understand!
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yes, I guessed something like that was the reason. However, I'm not sure why
the image should be loadable by paint programs - in most cases it will look
unintelligible. As far as I can see, hand-editing of a HF_16 TGA in a paint
program is impossible for any practical purposes.
And what about using 24/32 bit precision? These would still be valid TGA
images, the 24 bit version would not increase file size and could also be
read as a 16 bit HF (if a program doesn't support 24 bit precision but can
recognize the image as a HF). Which brings me to the question: what
identifies the file as a HF_16 TGA? Surely not only the fact that the blue
channel is empty?
Margus
Alexander Enzmann wrote:
>
> 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
|
|
| |
| |
|
|
|
|
| |
