Superfly and bad antialiasing
eclark1849 last edited by
@vilters He's not allowed to tell us why SM won't give us a collapsible Hierarchy?
I can't speak for SMSI. My affiliation with them ended in 2016.
Thanks for the response, Stefan. I did say I was just interested in your thinking "at that time", but that's all right. Let's let it drop.
@Deecey I think I worded that a bit weirdly... the 'about' right at the end, doesn't belong. I just meant to ask @stefan if he personally thought the antialiasing issue with PNGs would still be considered a bug so I know if it's worth putting a bug report through. Sounds like maybe it's more of a quirk of the PNG format.
I could honestly go on a big rant with the way Smith Micro treated you guys, especially right after you guys gave us the best version of Poser I've ever had the pleasure of using. But I doubt it would help anyone, or that SM will come to their senses...
@cobra - what application are you using to view the exported PNG files? Have you tried switching to TIFF & if so do you get the same issue? If you're rendering with Superfly have you tried unchecking Visible in Camera for the Ground or whatever environment you're using rather than using Holdout?
@caisson The renders go into my games as sprites... and that is where the real issue is since the image is put over the top of backgrounds. The glow or poor antialiasing doesn't affect all frames making it even more noticeable with animated sprites in a game... I can't pin down any cause as it seems almost random. I could, in theory, maybe just re-render the frames that this happened too.
However, the advice that was given earlier to try a different format, TIFs, for example, has been great, since hundreds of frames later and I still haven't come across this issue again.
Initially, I had no backdrop or ground visible to create my sprites, there was never any problem back then. I'm not 100% sure if this only affects SuperFly renders... but it seems probable since this didn't happen back when I was using Firefly instead. I didn't start using Holdout until this issue reared its head to try and get around it, but in the end, it looks like exporting my animation to PNGs was the real culprit.
h.elwood.gilliland last edited by
@Cobra Please attach the original frame images to your bug report.
That's interesting, so what I'm seeing is that in one frame it shows a fade to white, and in the other frame it shows a fade to black. This is a common issue with the interpretation of what "alpha" means -- is your background "purple" or is it "transparent"?
In PNG graphics (or any alpha channel graphic), I've struggled in other projects to know the meaning of "0" alpha -- as it turns out, an alpha of "0" is not necessarily associated with a color of "0,0,0" (black) .. for instance in some games, you see this artifact because the RGBA data has been encoded as "1,1,1,0" instead of "0,0,0,0"
@h.elwood.gilliland Thank you for your response. The backgrounds were transparent, I blew them up in size and added the background colour to make the antialiasing issue more prominent. If anyone views this forum with a white BG like me, they wouldn't have been able to see the issue on here otherwise.
I've decided to reproduce this with Andy2 & Andrea since that will make the results even more reproducible for the SM team. I applied the Andrea_FemBot material to Andrea which makes her translucent in SuperFly. This makes it even easier to see that in some of the PNGs of the same animation it is fading to black while others it tries to fade to white. With TIFs, it always fades to black so no issues there... just with the PNGs.
I've posted an example of this here but will send through unmodified versions of these through with my bug report for you.
h.elwood.gilliland last edited by
It's a common issue with rendering engines and the various filtering options. Strange that it happens every other frame .. perhaps another setting is causing the problem (like motion blur, lighting)
A workaround for this is to post-process the images or use chroma-key method to convert the image to transparent.
I know of one utility that sets alpha color to a specific color (black, or white, for example, uniformly), but I can't recall it exactly.
Examples of methods to clean this up:
GIMP batch script-fu: http://tuxtweaks.com/2010/06/how-to-fade-the-edges-of-images-with-gimp/
@h.elwood.gilliland I don't think lighting or motion blur are the cause.
While it's strange that not every frame is affected, PNGs do seem to be the issue. Here is another test, with a different workflow too.
I'm using default Poser lights for this one (Default Poser 1) and these are the settings I've used for all these renders, these new ones included.
Now instead of Make Movie, I've simply rendered my scene with the little camera icon, then selected export image selecting PNG then TIF. Both are the unmodified result below from the exact same render. You may have to put them over a darker background to spot the antialiasing around them. The PNG is the top one and TIF the bottom.
If the tiff doesn't load for some reason, both files are here in this zip anyway.
@Cobra - saving as PNG creates a straight alpha, saving as TIF or PSD creates a premultiplied alpha.
(To be more specific it's transparency for the first two as Photoshop only has an alpha channel in the PSD, & according to my reading, PNG supports 4 channels & the 4th is transparency not an alpha, but anyway).
Which gives the best result then depends on the software you are using to composite the end result in.
I've just tested in Photoshop & there the straight alpha is best for compositing. Both TIF & PSD, with premultiplied alphas, have edge artefacts - exactly like the ones you're getting from PNG.
That means the software you're using to composite requires premultiplied alpha - & that's why TIF works but PNG doesn't.
So basically what @stefan first posted. Poser would appear to be doing exactly what it should be doing.
I did find a video that explained the difference between straight & premultiplied alpha, I'll try to post the link ...
@caisson Hmm, I'm getting the white aura with pretty much anything I'm opening it up with on my end. My simple workaround is to export the TIFFs and batch convert them into PNGs (and also auto-crop them while I'm at it) using XnConvert. That way I still get the PNGs I want, without the antialiasing issue I was having.
The strangest thing with exporting multiple frames as PNGs as I was doing before is how not every frame had the thin white aura around them, most came out as clean as the TIFFs for me. So while I have a workaround thanks to our friendly forum members... this may be something @h-elwood-gilliland may still want his team to look into.