 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmail com> wrote:
> :)
>
> ImageMagick has been popular for a long time.
>
> There's some history here:
> https://en.wikipedia.org/wiki/ImageMagick
How about that - that is the program I used in the early '90s. I had forgotten
about it!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Dave Blandston" <nomail@nomail> wrote:
> Using a paint program to adjust the transparency is what I'm currently doing to
> achieve the result that I want but it's not a perfect solution because of the
> number of images involved. I'm using the "transmit all" feature to animate some
> elements of a website mockup animation that fade in and fade out, such as
> buttons and pop-ups and such. Images that don't require different levels of
> transparency work great and I can use "transmit all," and only one copy of the
> image needs to be made. But images that require part of the image to be fully
> transparent exhibit the problem in the image posted above, so I can't use
> "transmit all" and I have to make many copies of the image with the varying
> levels of transparency which is very tedious. That's why I was curious if there
> was a better way so I just thought I'd ask. I should have a sample animation
> ready to post soon that will make this more clear. It's a fun project.
This seems to be very weird behaviour. Have you checked somehow to see that the
alpha channel isn't as fully transparent as you think or is corrupted in some
way?
A graphics editor with an eyedropper tool usually displays the rgbt values.
Not sure if this well help, and it's a hacky workaround, but maybe you can use
different image mapped shapes - like a cylinder or disc for the ABBA image? Or
use intersection or difference? Just a thought.
Also make sure your scene is set up correctly. Not sure about that background
statement. I'd kill that and put up a plane or other object, just to see if
there isn't some strange under-the-hood thing going on with those
angle-independent keywords.
Good luck,
BE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> This seems to be very weird behaviour. Have you checked somehow to see that the
> alpha channel isn't as fully transparent as you think or is corrupted in some
> way?
> A graphics editor with an eyedropper tool usually displays the rgbt values.
>
> Not sure if this well help, and it's a hacky workaround, but maybe you can use
> different image mapped shapes - like a cylinder or disc for the ABBA image? Or
> use intersection or difference? Just a thought.
>
> Also make sure your scene is set up correctly. Not sure about that background
> statement. I'd kill that and put up a plane or other object, just to see if
> there isn't some strange under-the-hood thing going on with those
> angle-independent keywords.
>
> Good luck,
>
> BE
Placing an object in the background doesn't change anything unfortunately. The
problem first appeared with a box {} as a background.
I hadn't thought of the possibility that the image editing program I'm using
(Paint.net) might be doing something weird with the alpha channel so I made a
test image with Photoshop and it didn't work either.
The ABBA image is just a random image for demonstration. The goal is to be able
to supply an image of a website element (button, logo, et cetera) and make it
fade in and out during an animation sequence. It's working great except for
images with transparent portions. It gets even weirder sometimes - I tried the
following layers, from back to front: A totally opaque box (the frame of a
video), an image with opaque areas and transparent areas (animated text), a
white box that was fading from opaque to transparent with "transmit all" to
reveal the objects behind it, a box with opaque and transparent areas (video
player controls), a box with a transparent window for the video to show through,
then another box with a transparent window that represents a web browser frame.
Out of all these objects, I don't think there was one certain one that wrecked
the scene but a combination, since other combinations do work. But this
particular combination resulted in very odd transparency areas. I think there's
just something strange going on with how POV-Ray handles .png alpha channels.
I'll attach a sample image using most of the items in the list above (everything
except the fading white box, which I removed) so maybe it will make more sense.
Have a great day!
Post a reply to this message
Attachments:
Download 'testframe.jpg' (317 KB)
Preview of image 'testframe.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
So, I don't know where you're experiencing problems, since my little test scene
with a transparent background png I grabbed from the web seems to work fine.
Perhaps you have some complicating factor in your scene, or maybe some
strange/incorrect syntax/structure to your image_map statement.
(I'm still battling with the finer points of cutaway_textures....)
Post a reply to this message
Attachments:
Download 'transmit_tests.png' (55 KB)
Preview of image 'transmit_tests.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I don't know where you're experiencing problems, since my little test scene
> with a transparent background png I grabbed from the web seems to work fine.
>
> Perhaps you have some complicating factor in your scene, or maybe some
> strange/incorrect syntax/structure to your image_map statement.
>
> (I'm still battling with the finer points of cutaway_textures....)
This issue may be what the statement "New as of version 3.8, using filter all
and transmit all on an image file with an alpha channel is now supported
properly (requires #version 3.8 or higher)" is referring to in the new
documentation. I haven't upgraded yet.
That being said, if you're interested in making sure that alpha channels are
working properly in version 3.8, use a color other than white for the
background. As you can see from the sample image I posted, the RGB components of
transparent pixels do alter the final image. This effect isn't visible with a
white background. The RGB components of the transparent pixels could be <255,
255, 255>, <0, 0, 0>, or they could be the unchanged remains of a photo, or they
could be random I suppose. Version 3.7 produces varying results based on these
different conditions - see the attached image.
Post a reply to this message
Attachments:
Download 'untitled.jpg' (303 KB)
Preview of image 'untitled.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This was addressed a few years ago...
https://news.povray.org/povray.binaries.images/thread/%3C569528cc%241%40news.povray.org%3E/
Interestingly enough, the fellow who brought it up (Kenneth) was doing exactly
what I'm doing, which is making image_maps fade in and out during animation.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Dave Blandston" <nomail@nomail> wrote:
> This was addressed a few years ago...
>
>
https://news.povray.org/povray.binaries.images/thread/%3C569528cc%241%40news.povray.org%3E/
>
> Interestingly enough, the fellow who brought it up (Kenneth) was doing exactly
> what I'm doing, which is making image_maps fade in and out during animation.
Have you tried adding "premultiplied off" in between the filename and "transmit
all" ?
Seems to work for me.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> Have you tried adding "premultiplied off" in between the filename and "transmit
> all" ?
>
> Seems to work for me.
Yep the premultiplied feature was the first thing I tried when I noticed that
things weren't working the way I expected. According to the discussion in 2016,
Mister Lipka explained the source of the problem and corrected it in version
3.71. I don't consider myself to be a suitable beta tester (it took me over nine
years to discover this issue) so I'm using version 3.7.
What I should have done from the beginning is write the program in C which is
more suitable for this project. But it's pretty much done now and this is a
minor problem that I've been able to work around. The explanation from Mister
Lipka is very interesting though.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Dave Blandston" <nomail@nomail> wrote:
> Yep the premultiplied feature was the first thing I tried when I noticed that
> things weren't working the way I expected.
Well then you are WAAAAAAAAAAAAAAAAAAAAAYYYYYYYYYY ahead of me in that respect,
because I was blissfully unaware the mere existence of such a keyword.
> What I should have done from the beginning is write the program in C which is
> more suitable for this project. But it's pretty much done now and this is a
> minor problem that I've been able to work around. The explanation from Mister
> Lipka is very interesting though.
What you should have done from the beginning is _upgrade to version 3.8_.
Go do that now.
......
.... waiting ...
.....
Are you done? Good. Everything should be working now. :D
tl;dr
The only other thing I can think of would be to try and render each of the
images as an image_map with a transparent background in POV-Ray, and use those
renders instead of the original images.
POV-Ray can't control the render size/resolution from within SDL, BUT I think
there might be a way using an ini file and a test in the SDL to check for the
existence of a file to write the image size to an ASCII file (overwrite the ini
file) on the first pass (frame 1 of an animation) and then maybe the rewritten
ini file will use that info on the second pass to render the image at the proper
size.
Steal some code from the insert menu render scripts, and I think you might be
able to process all of the images. In fact, I think there's code in those
insert render scripts to read the desired render size of each image from the SDL
code or something.... It was clever....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> Well then you are WAAAAAAAAAAAAAAAAAAAAAYYYYYYYYYY ahead of me in that respect,
> because I was blissfully unaware the mere existence of such a keyword.
>
> > What I should have done from the beginning is write the program in C which is
> > more suitable for this project. But it's pretty much done now and this is a
> > minor problem that I've been able to work around. The explanation from Mister
> > Lipka is very interesting though.
>
> What you should have done from the beginning is _upgrade to version 3.8_.
>
> Go do that now.
>
> ......
>
>
> .... waiting ...
>
>
> .....
>
> Are you done? Good. Everything should be working now. :D
Oh shoot I decided to give it a try but since I bought a new computer a few
years ago I haven't set it up to compile stuff so it'll be a little bit more of
a job that will have to wait until I build up the motivation.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
