 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
https://wiki.povray.org/content/Reference:Image_Map#The_Filter_and_Transmit_Bitmap_Modifiers
I'm trying filter all and transmit all, and there is no observable filter or
transmit.
When I try filter 0, 0.99, I get
Parse Error: Keyword 'transmit' cannot be used with non color-mapped image.
So either I'm doing something very wrong, or this part of the code is _broken_,
or things have changed, and the documentation does not reflect this.
Can anyone verify / solve / workaround?
- BE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 19/04/2024 om 04:11 schreef Bald Eagle:
>
>
https://wiki.povray.org/content/Reference:Image_Map#The_Filter_and_Transmit_Bitmap_Modifiers
>
> I'm trying filter all and transmit all, and there is no observable filter or
> transmit.
>
> When I try filter 0, 0.99, I get
>
> Parse Error: Keyword 'transmit' cannot be used with non color-mapped image.
>
> So either I'm doing something very wrong, or this part of the code is _broken_,
> or things have changed, and the documentation does not reflect this.
>
> Can anyone verify / solve / workaround?
>
> - BE
>
>
Should work I guess. I use them all the time, with Poser figures in
particular. Example:
#declare p_map13=pigment {image_map{jpeg "JamesHair1.jpg" gamma srgb
interpolate 2 transmit all 0 filter all 0} }
I never used that wiki example though. I wonder if that is not
specifically for GIF image formats only...?
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: transmit does not work with image maps
Date: 19 Apr 2024 07:27:54
Message: <6622553a$1@news.povray.org>
|
|
|
| |
| |
|
|
On 4/19/24 02:36, Thomas de Groot wrote:
> I never used that wiki example though. I wonder if that is not
> specifically for GIF image formats only...?
You've got it Thomas. When you specify an integer rather than 'all' you
are asking the 'filter' and 'transmit' keywords to modify an indexed
image's filter / transmit value for a particular index 'n'. This is not
possible with non-indexed images (probably not too, where indexes are
out of range).
Several image formats support internal formats using indexes / tables of
color/grey values. I'm unsure of the complete, working / supported list
for POV-Ray? The gif format is always indexed and it's certainly one
which works.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 19-4-2024 om 13:27 schreef William F Pokorny:
> On 4/19/24 02:36, Thomas de Groot wrote:
>> I never used that wiki example though. I wonder if that is not
>> specifically for GIF image formats only...?
>
> You've got it Thomas. When you specify an integer rather than 'all' you
> are asking the 'filter' and 'transmit' keywords to modify an indexed
> image's filter / transmit value for a particular index 'n'. This is not
> possible with non-indexed images (probably not too, where indexes are
> out of range).
>
> Several image formats support internal formats using indexes / tables of
> color/grey values. I'm unsure of the complete, working / supported list
> for POV-Ray? The gif format is always indexed and it's certainly one
> which works.
>
> Bill P.
Thank you Bill. I suspected something like this but it has been such a
long time since I last manipulated gif-format images that the info had
become ghost-like in my mind...
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
When using 'transmit all' with typical jpeg and png images, there is an
unfortunate mix of flaws in both official v3.7.0 and in the v3.8 betas--
different kinds of problems in each, especially with alpha-channel images.
See this related post from December 2022 (with some function solutions further
down in the post)...
https://news.povray.org/povray.binaries.images/thread/%3Cweb.63ac0323f59cfc766631b53a9334df62%40news.povray.org%3E/?mto
p=438912
and this one from 2016...
https://news.povray.org/povray.binaries.images/thread/%3C569528cc%241%40news.povray.org%3E/
According to POV-ray's documentation, transmit all ...some value... *should*
work correctly even on non-GIF images. I have successfully used it many times in
the distant past. But currently, this is the situation:
In 'official' v3.7.0, it does work correctly with typical 24-bit .jpeg's and
png's -- but has an odd problem with 32-bit alpha-channel images that already
have a mask, where the 'invisible' parts of the alpha mask start showing up as
the image's complementary colors instead. (Developer Christoph Lipka fixed that
particular flaw back in 2016, in one of the ongoing v3.71 development releases
that 'piggy-backed' on v3.7.)
But in the v3.8 beta releases, something changed-- transmit all is completely
*ignored*, when used with typical 24-bit images. However, it DOES
work correctly if those images are re-saved as 32-bit .png. I currently use the
free paint.net app to do this-- it creates a 'dummy' alpha channel, which is
apparently needed now. Images with an *actual* alpha channel also behave
properly. (If the #version in the scene is changed to 3.7 instead of 3.8, the
behavior is the same as using v3.7.0 itself: transmit all works as advertised
on typical 24-bit images...but with the prior 32-bit alpha-channel problem.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmail com> wrote:
> According to POV-ray's documentation, transmit all ...some value... *should*
> work correctly even on non-GIF images. I have successfully used it many times in
> the distant past.
Yeah, see, I thought so. Good to know it's "just" buggy behaviour.
> I currently use the
> free paint.net app to do this-- it creates a 'dummy' alpha channel, which is
I wanted to re-install that, but apparently they don't support a Win 7 version
anymore and I can't find an install package for it. :(
Thanks for the info!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 21/04/2024 om 18:35 schreef Kenneth:
> When using 'transmit all' with typical jpeg and png images, there is an
> unfortunate mix of flaws in both official v3.7.0 and in the v3.8 betas--
> different kinds of problems in each, especially with alpha-channel images.
> See this related post from December 2022 (with some function solutions further
> down in the post)...
>
> [snip]
Thanks Kenneth! Somehow, I never use those cases where the bug shows, it
appears. Good to know if I come across the problem.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> But in the v3.8 beta releases, something changed-- transmit all is
> completely *ignored*, when used with typical 24-bit images. However, it DOES
> work correctly if those images are re-saved as 32-bit .png. I currently use
> the free paint.net app to do this-- it creates a 'dummy' [white] alpha
> channel, which is apparently needed now...
[Bald Eagle wrote:]
> I wanted to re-install that, but apparently they don't support a Win 7
> version anymore and I can't find an install package for it. :(
I just discovered another way to get this 24-bit-to-32-bit image conversion, no
external app required. It can be done *within* POV-ray, by *re-rendering* the
image there as a 1:1 reproduction .png file and using OutPut_Alpha=on in
your .ini file (or +ua on the command line). This produces a 32-bit image with
a dummy white alpha channel, just like paint.net. Then 'transmit all' can
work correctly with it. I have included a small image-copying scene file to do
this, for your enjoyment ;-)
Surprisingly, this new image also works correctly in v3.7.0 re: transmit all
-- which has a problem with typical 32-bit alpha-channel images. I think this is
because the dummy alpha-channel *is* pure white (meaning fully 'opaque', no
transparency.) Whereas, the translucent/transparent areas in usual
alpha-channels are gray-to-black, with black representing full transparency.
It's *those* areas that cause the odd 'transmit all' color-reversal problem in
v3.7 (IF there are image colors in those areas.)
(BTW, the following bit of info in the POV-ray documentation at '3.6.2.6.4 Using
the Alpha Channel' can be ignored for this 1:1 re-render):
"Note: In version 3.7 alpha handling for image file output has changed.
Effectively, the background now requires a filter or transmit value in order for
alpha transparency to work properly."
-------------
#version 3.8; // 3.7 also works for this
global_settings{assumed_gamma 1.0}
//#declare IMAGE_DIMEN = <1152,921>; // pixel size of the original image to be
// copied. For perfect 1:1 final image size, enter these values onto
// the command line-- like +w1152 +h921 -- which overrides any .ini file
// resolutions.
// Or, you could use the max_extent(...) keyword to automatically get the
// dimensions of the image...
#declare IMG = pigment{image_map{jpeg "my image.jpg" gamma 2.2}} // must be
// #declared first. Do not use 'interpolate' for 1:1 reproduction. 'Once' is
// not necessary either. Gamma setting is optional.
#declare IMAGE_DIMEN = max_extent(IMG);
camera {
orthographic // perspective or orthographic, same result
location <.5*(IMAGE_DIMEN.x/IMAGE_DIMEN.y), .5, -1> // u and v also work
look_at <.5*(IMAGE_DIMEN.x/IMAGE_DIMEN.y), .5, 0>
right x*image_width/image_height
//angle 67 // Leave this out for 1:1 render! The default angle is not 67.
}
// the original image, on a box to copy it
box{0,<1,1,0> // zero-thickness is OK
texture{
pigment{IMG}
finish{ambient 1 emission 0 diffuse 0}
}
scale <IMAGE_DIMEN.x,IMAGE_DIMEN.y,1>/IMAGE_DIMEN.y
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 21/04/2024 om 18:35 schreef Kenneth:
> > When using 'transmit all' with typical jpeg and png images, there is an
> > unfortunate mix of flaws in both official v3.7.0 and in the v3.8 betas--
> > different kinds of problems in each, especially with alpha-channel images.
> > See this related post from December 2022 (with some function solutions further
> > down in the post)...
> >
> > [snip]
>
> Thanks Kenneth! Somehow, I never use those cases where the bug shows, it
> appears. Good to know if I come across the problem.
>
Over the years, I have come to realize that at least part of the transmit all /
color-reversal problem in v3.7 with alpha-channel images depends on how external
apps actually construct their own alpha channels, and the steps required. My old
version of Photoshop vs. the current paint.net app (as examples) go about it in
completely different ways, at least as far as the user is concerned. And
POV-ray's transmit all results show somewhat different flaws from each, in v3.7.
Dave Blandston's image examples in his 2022 thread show the same kind of results
I used to get with Photoshop.
I have not fully tested POV-ray's own alpha-channel image output, when brought
back into POV-ray and applied to an object, then using transmit all with it. In
the 3.8 betas, my few tests look nicely correct; in 3.7, the
translucent/transparent parts of the alpha channel (gray-to-black) start showing
up as a kind of ghostly translucent white-- although this might be hard to see
when used with other layered textures.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> According to POV-ray's documentation, transmit all ...some value... *should*
> work correctly even on non-GIF images. I have successfully used it many
> times in the distant past. But currently, this is the situation:
>
> In 'official' v3.7.0, it does work correctly with typical 24-bit .jpeg's and
> png's -- but has an odd problem with 32-bit alpha-channel images that already
> have a mask...
>
> But in the v3.8 beta releases, something changed-- transmit all is
> completely *ignored*, when used with typical 24-bit images. However, it DOES
> work correctly if those images are re-saved as 32-bit .png...
I was looking at one of my old test-scene files, and realized that there is yet
another simple workaround for the 'transmit all' problem in the 3.8 betas...
which ALSO solves the odd problem in 3.7.0 with alpha-channel images: using an
averaged pigment_map with a plain 'transmit' value instead. The relative weights
of the average determine the translucency:
pigment{
average
pigment_map{
[0.6 image_map{png "my image.png" once interpolate 2]
// .jpeg, .png, .tiff; can an have an alpha-channel mask too.
[0.4 transmit 1.0]
}
}
Of course, this would require re-editing old scene files to replace the original
'transmit all', which could be cumbersome. (BTW, tiff images may or may not need
the new 'premultiplied on/off' keyword for this, if they have an actual
alpha-channel mask. In my tests, I had to turn it off to get better visual
results. I guess it depends on the app that creates such images.)
The simple construct above makes me wonder if 3.8's problem with 'transmit all'
(re: typical 24-bit images) may be the result of a minor source code difference
between it and plain 'transmit'...possibly a change that was introduced by
mistake.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
