 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This question is in regards to a post I made earlier today in the general forum
(See
http://news.povray.org/povray.general/thread/%3Cweb.503e0aa3d8fa7d9cd9fdb3af0%40news.povray.org%3E/)
Specifically it relates to the 'image_map' keyword and how 'filter' and
'transmit' colors are specified. Currently they are specified by integer values
that serve as index numbers. (See documentation at
http://www.povray.org/documentation/view/3.6.1/337/)
How hard would it be to make it so instead of requiring an index number, only
the RGB value of the color in question was needed?
For example instead of something like (as detailed at the above documentation
location)
image_map {
gif "mypic.gif"
filter 0, 0.5 // Make color 0 50% filtered transparent
filter 5, 1.0 // Make color 5 100% filtered transparent
transmit 8, 0.3 // Make color 8 30% non-filtered transparent
}
something like
image_map {
gif "mypic.gif"
filter <0,0,0>, 0.5
// RGB value of color 0, make it 50% filtered transparent
filter <0,128,0>, 1.0
// RGB value of color 5, make it 50% filtered transparent
transmit <0,255,255>, 0.3
// RGB value of color 8, make it 30% non-filtered transparent
}
I'm assuming for such a convention that if the color is not present there is no
filter or transmit applied.
Any thoughts?
-Jeff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 31.08.2012 00:20, schrieb Woody:
> For example instead of something like (as detailed at the above documentation
> location)
>
> image_map {
> gif "mypic.gif"
> filter 0, 0.5 // Make color 0 50% filtered transparent
> filter 5, 1.0 // Make color 5 100% filtered transparent
> transmit 8, 0.3 // Make color 8 30% non-filtered transparent
> }
>
> something like
>
> image_map {
> gif "mypic.gif"
> filter <0,0,0>, 0.5
> // RGB value of color 0, make it 50% filtered transparent
> filter <0,128,0>, 1.0
> // RGB value of color 5, make it 50% filtered transparent
> transmit <0,255,255>, 0.3
> // RGB value of color 8, make it 30% non-filtered transparent
> }
>
> I'm assuming for such a convention that if the color is not present there is no
> filter or transmit applied.
>
> Any thoughts?
Yes, this one: Why bother with old-fashioned GIF files anyway?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>
> Yes, this one: Why bother with old-fashioned GIF files anyway?
I was just using the example given in the documentation to avoid coming up with
my own example. I suppose it could just as easily been a BMP, IFF or PNG file.
Are you suggessting requiring the PNG format and using its implied transperency
scheme?
-Jeff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 31.08.2012 19:01, schrieb Woody:
>>
>> Yes, this one: Why bother with old-fashioned GIF files anyway?
>
> I was just using the example given in the documentation to avoid coming up with
> my own example. I suppose it could just as easily been a BMP, IFF or PNG file.
>
> Are you suggessting requiring the PNG format and using its implied transperency
> scheme?
Well, that's what I'd recommend, at any rate.
If you told us what you're actually trying to achieve, rather than what
tool you happen to have in mind for that purpose, we might also be able
to come up with a different approach to suit your needs.
The approach you suggests seems rather straightforward at first glance,
but (A) I fail to see where it's actually of use, and (B) at second
glance it actually turns out to be non-trivial not only to implement,
but even more so to even specify in a consistent manner. For starters,
you suggest to specify the color values in units from 0 to 255, instead
of the 0.0 to 1.0 range used everywhere else throughout POV-Ray; but the
trouble only barely begins there: Are these colors raw image values?
Linear values? sRGB values? For consistency the colors should be
interpreted as "cooked" to fit POV-Ray's color model (subject to
assumed_gamma and all), but I suspect this would make the whole thing
pretty pointless.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> Well, that's what I'd recommend, at any rate.
>
> If you told us what you're actually trying to achieve, rather than what
> tool you happen to have in mind for that purpose, we might also be able
> to come up with a different approach to suit your needs.
>
> The approach you suggests seems rather straightforward at first glance,
> but (A) I fail to see where it's actually of use, and (B) at second
> glance it actually turns out to be non-trivial not only to implement,
> but even more so to even specify in a consistent manner. For starters,
> you suggest to specify the color values in units from 0 to 255, instead
> of the 0.0 to 1.0 range used everywhere else throughout POV-Ray; but the
> trouble only barely begins there: Are these colors raw image values?
> Linear values? sRGB values? For consistency the colors should be
> interpreted as "cooked" to fit POV-Ray's color model (subject to
> assumed_gamma and all), but I suspect this would make the whole thing
> pretty pointless.
I can see your point.
The whole cause of this post had to do with a problem I was having. I had an
image with quite a few colors that were otherwise indistinguishable to the human
eye. Because of that, finding the index of the exact color I wanted to make
transparent would have been difficult.
But you are right, there are quite a few problems with that, and would be of
marginal benefit.
-Jeff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
