Welcome to TVPaint Community forums !

ematecki wrote:...to 10 (slow but small).

And if Hilary's computer is not quite powerful, then it can be veeeeeery slow or even crash.

ematecki wrote:PNG is "equally" lossless whatever compression you choose. It will ALWAYS give you back the exact same pixels you put in.

With compression=1, it does a quick job at compression, but that gives quite big files.
With compression=10, it tries really hard to make your file the smallest possible, and that takes times.
So depending on whether you choose to save time or disk space, you choose from 1 (fast but big) to 10 (slow but small).

Thank you. That is helpful to know. For some reason I have never understood it correctly , but now I get it. I was thinking of the 1- through - 10 compression like this: low quality (1) - to - high quality (10) . I did not understand that PNG is lossless no matter what compression setting is used, but that the setting (1 - through - 10) refers to the amount of time it takes to process the compression and how large or small the file size will be.

Hi Everyone,
Thank you all for the helpful advice. I will put it all in place. Also I was a bit random with that screen grab so yes there are some things on there that shouldn't be. No there are no video layers - they are all png imports from Maya png export. Regarding the 1 versus 10 on the 'lossless' front. I chose 10 as a value because when I went to test my final conform pipeline with my editor they were superior quality. Or at least to our eyes at the time. Given what was said about these having to 'crunch the image' taking processing power this could be my problem. I don't think the specs on my computer are the issue. Anyway that said I will run through the advice this morning and see what happens. Thanks as always for the speedy response!
Hilary

By the way, does this same principal apply to AVI (Internal) Motion-JPEG Quality which can range from 1% to 100% but its claim to fame is that it will always remain lossless (I use 85%)?

OK - Success! So I think the issue was the RGBA (as well as background being unnecessarily checked) on the BG layer.Plus I would always start my exports with these detailed BG layers. This is the one that has the most info in it. Plus as it would crash I would overwrite the first few files on the second attempt and I think this was confusing the number naming system. It does seem to make a slight difference to make sure there is an under score in the file directory folder itself. So for the most detailed art layer it was:
25 minutes to render 76 frames. At #10 setting each image was 1.8 MB
Overlay layers with less image on them exported WITH an alpha (RGBA) went quickly
2 minute 76 frames. At #10 setting each image was 54KB
BUT when I tried the #1 setting just to see - as predicted the time to render was twice as fast (1 min) but the file size really spiked to 9MB! I looked at them side by side and have to say can't see the difference(see image below) That said at my editors we were looking at an image on a very good monitor as opposed to the cintiq. So will check with him to see but I think I will stick with 10 for file compression if nothing else. Have way too much to do to have a single image balloon to 9MBs.

Paul Fierlinger wrote:By the way, does this same principal apply to AVI (Internal) Motion-JPEG Quality which can range from 1% to 100% but its claim to fame is that it will always remain lossless (I use 85%)?

Nope. For AVI or JPEG sequences, lowering the value affects the quality.

Thanks, Elodie. But there doesn't seem to be any discernible difference in quality between 80- and 100%. Maybe I should start a new thread on this.

Lower the quality to 10% and you will notice immediately there is a terrible loss of quality (it works both ways).

One last note on the PNGs - I see that when the PNG has no alpha it is 24 bit (RGB) but when exported with an alpha (RGBA) it is 32 bit. I was reading about the differences in the two and there is a quality difference with gradients and subtle shades (as well as transparencies obviously) I exported 2 single frames of a BG - one at 24bit and the other at 32 bit. I can see some very sublte colour differences - again going to check with editor. Knowing that a full image exported with RGBA makes TVP crash is there any thoughts in having the option of a 32Bit PNG with no alpha?

one at 24bit and the other at 32 bit. I can see some very sublte colour differences

ok, but premultiplied or not ? because it changes everything.

The RGBA 32 Bit file at premultiply is slightly better than the no multiply. But we are still comparing 32 bit with 32bit as the 24bit option doesn't give you the choice to pre or no multiple. In AE when you choose the RGBA option for a PNG seq export (with no option for multiply or premultiply) it automatically goes from a million colours to a million + which is why I am thinking that in theory the TVP export for a PNG with the most colours would be PNG 32Bit Premultiply RGBA. The setting that makes things crash(on my computer anyway). Admittedly the visual differences are super minor - just curious. OR to go back to the beginning if I had 32 Gigs of ram instead of 16 then it might be able to handle the full 2048 X 1152 colour seq with alpha

Here’s a quick explanation of the three PNG formats :
- PNG-8 : 8-bit PNG, meaning the image is 8 bits per pixel
- PNG-24 : 24-bit PNG, 24 bits per pixel. PNG-24 can handle a lot more color and is good for complex images with lots of color such as photographs (just like JPEG), while PNG-8 is more optimized for things with simple colors, such as logos, icons, buttons...
- PNG-32 : PNG32 is PNG24 but with support for full alpha transparency. This means you can have varying degrees of transparency for each pixel, whereas GIFs can only have transparency turned on or off for each pixel. Therefore, when placed on complex or ill-matching backgrounds, transparent PNGs will have nice smooth edges.

Regarding non-premultiplied and premultiplied, here’s the official PNG specs ( http://www.w3.org/TR/PNG-Rationale.html ... lied-alpha" onclick="window.open(this.href);return false; ) explaining why premultiplied is bad :

PNG uses "unassociated" or "non-premultiplied" alpha so that images with separate transparency masks can be stored losslessly. Another common technique, "premultiplied alpha", stores pixel values premultiplied by the alpha fraction; in effect, the image is already composited against a black background. Any image data hidden by the transparency mask is irretrievably lost by that method, since multiplying by a zero alpha value always produces zero.
Some image rendering techniques generate images with premultiplied alpha (the alpha value actually represents how much of the pixel is covered by the image). This representation can be converted to PNG by dividing the sample values by alpha, except where alpha is zero. The result will look good if displayed by a viewer that handles alpha properly, but will not look very good if the viewer ignores the alpha channel.
Although each form of alpha storage has its advantages, we did not want to require all PNG viewers to handle both forms. We standardized on non-premultiplied alpha as being the lossless and more general case.

As Eric told a few times on the forum :

PNGs should never be premultiplied, that's why the "(PreMult)" is between parentheses.
Some software where buggy last century, that's why TVPaint allowed saving premultiplied PNG.