|
 |
Le 2023-03-26 à 18:57, William F Pokorny a écrit :
> On 3/26/23 15:36, Leroy wrote:
>> What I'm kind of proud of is that the palette is special. The blue
>> part of the
>> each palette element matches that element number. So a pigment
>> function that
>> outputs blue matches the old standard Height field. I didn't plan on
>> that. When
>> I set it up all those years ago I did it that way because it was
>> easier to
>> code.
>>
>> Here One that shows the full 256 range
>
> Thanks! Played with it a while and yep, these exactly the kind that do
> work and I've dropped support for them in my povr code... There are many
> format variations with tga and I thought you might be using something else.
>
> The tga indexed input POV-Ray allows, can be 8 bit (256 deep) or 16 bit
> (65535 deep). The latter form won't work correctly with the index method
> in existing POV-Ray versions. It'll do some sort of wrap.
>
> I looked around quickly for a converter which would convert to another
> image format directly from the index values, but had no luck. Something
> must exist somewhere I'd guess.
>
> In general our image support is decent, but we don't support everything,
> every format can do by any stretch. With povr I don't want to burn my
> limited time on this image support work and I have considered dropping
> some formats completely. It's just a resource thing. But, I don't know,
> maybe there is a way to make use of an external conversion library or
> something.
>
> Bill P.
Remember that 8 bits and less are paletted formats and that 16 or more
are non-paletted.
IIRC, in hight fields, when the image is 24 bits, the red and green
channels are used to to represent the high (green) and low (red) bytes
of a 16 bits value and the blue channel is ignored.
16 bits is often called high colour and 24 and 32 bit are called true
colour.
Post a reply to this message
|
 |