OTOY Forums

Hi guys,

Since we are starting a new project, I'd like to optimize our file workflow a bit. We usually work in 16 bit png with compositing done in AE.
Frankly, we didn't have any noticeable problems over the last years so I was a little confused reading this blogpost about how big of a no go .png is

https://www.elsksa.me/scientia/cgi-offl ... mat-debunk

Since we do a lot of motion design, 32 bit editing is rarely needed. And altough we do a lot of finishing in AE, I always try to get a lot of the final look already in octane. That said, we use the baked in ACES workflow and are pretty satisfied with it. Going the ACES route in combination with AE often is not an option due to time and budget limitations.

So, to get to the core: What files are you guys using and what's your typical workflow for full CG work with compositing?

Saving through the C4D dialouge is already abandoned but seeing that .TIFF uses almost the triple amount of storage, I have some concerns about it. Especially since you can't use a compression mode inside the octane save options, or am I missing something? .exr is smaller (not as small as .png though) but hell, AE gets slow as fuck.
Quality wise, I honestly can't see a major downside in .png... maybe someone could show some examples?

Looking forward to reading your thoughts about it.

Edit: What I just discovered: the alpha looks bad when saving via octane, no matter if I interpret it in AE as straight or unmatted. Any suggestions how to fix that?

The elsksa posts, whilst useful, can be over the top in demonising certain workflows. If you read them all, unless you're using their preferred colour management system, file format and render settings, you're a heathen that should be burnt at the stake.

PNG is perfectly fine to use

The c4d save page is perfectly fine to use.

You can get more data, in better formats by using the octane save page, but the real-world implications outside of a full hollywood production pipeline are not significant. The biggest downsides of png are the slow save speeds, if you're making 8k stills then you may spend quite a few seconds just saving the file. On a 20 minute render, 30 seconds of saving is nothing; but if you have 1 minute renders, then 30 seconds of saving could be a significant hit per frame rendered.

At the studio here, we render most of our images with all colour and grading adjustments baked into 8 bit png files. Sometimes we'll use 16 bit if we know that there will need to be brightness adjustments on dark scenes. Sometimes we'll render to 16 bit dwaa compressed exr files if we want to do more grading in post. But truth is 8bit c4d saved png files are the bulk of what we output because we're getting the lighting and grading ore or less as we want it in-camera so to speak.

Overall it depends on the nature and turnaround time of your projects. If you're firing out dozens or renders per day and your current system works, I would stick with it. If you're doing it for the art and have plenty of time, then yes you can push further by going with post-grading friendly file formats

Hi Keewe,

KeeWe wrote: Since we are starting a new project, I'd like to optimize our file workflow a bit. We usually work in 16 bit png with compositing done in AE.
Frankly, we didn't have any noticeable problems over the last years so I was a little confused reading this blogpost about how big of a no go .png is

Great initiative. However, there is a nuance between "there are no issues" and "it hasn't yet been noticed". Issues are undeniably occurring by the nature of the workflow (specifically that file format) and its many limitations. As the post does mention, it is simply inappropriate for being a "production" file format, one that will encode and contain various forms of data that will be handled in post.

KeeWe wrote: Since we do a lot of motion design, 32 bit editing is rarely needed.

I've numerously mentioned to not go for 32-bit for "all export types". It's also written in one (or several) of my pages. 16-bit for beauty and equivalent, 32-bit for data AOVs is basically the rule of thumb.

KeeWe wrote: And altough we do a lot of finishing in AE, I always try to get a lot of the final look already in octane. That said, we use the baked in ACES workflow and are pretty satisfied with it. Going the ACES route in combination with AE often is not an option due to time and budget limitations.

In-renderer finishing is acceptable for preview purposes but simply not feasible for any post-work requirements (implying, integer file formats). ACES is an other story, which hides its own set of issues. ACES (≤1.2) is unequivocally subject to it. It's well known and adding AE (or any Adobe software), is even more prone to flaws, technical (software) and user-errors. However, going the post route with any OCIO package is not that much slowing down the workflow and shouldn't be a huge budget limitation. I don't know the details and business context, though.

KeeWe wrote: Saving through the C4D dialouge is already abandoned but seeing that .TIFF uses almost the triple amount of storage, I have some concerns about it. Especially since you can't use a compression mode inside the octane save options, or am I missing something? .exr is smaller (not as small as .png though) but hell, AE gets slow as fuck.

This tells me you haven't consulted the whole page! If AE is slow with any EXR variants, it's an AE issue, not necessarily EXR (I'm speculating, as I don't have AE). PNG has disappointing performance and, as a reminder, was never designed for CGI or professional digital imaging applications, while EXR have been, joined by a few others.

KeeWe wrote: Edit: What I just discovered: the alpha looks bad when saving via octane, no matter if I interpret it in AE as straight or unmatted. Any suggestions how to fix that?

I've got a whole page coming up about "alpha" as I see many people confused about it, the workflow. Many will be surprised but I've spoiled some of it already across other pages and this forum. A good starting point would be to encode transparency via EXR or TIFF. Anything to avoid PNG will be beneficial and the right path.

Thanks boxfx for the kind words. In case clarifications are required:

boxfx wrote:PNG is perfectly fine to use

EXR or TIFF, all the way. PNG has been proven to be inappropriate in various cases. It's a spread of misinformation to write such claim.

boxfx wrote: You can get more data, in better formats by using the octane save page, but the real-world implications outside of a full hollywood production pipeline are not significant.

Individuals are also concerned!

boxfx wrote: At the studio here, we render most of our images with all colour and grading adjustments baked into 8 bit png files. Sometimes we'll use 16 bit if we know that there will need to be brightness adjustments on dark scenes. Sometimes we'll render to 16 bit dwaa compressed exr files if we want to do more grading in post. But truth is 8bit c4d saved png files are the bulk of what we output because we're getting the lighting and grading ore or less as we want it in-camera so to speak.

Following the in-camera analogy, EXR would be the closest equivalent to a raw file. Production cameras offer log-encoded lightweight recording options, typically Apple ProRes, let's say that it would be analogous to TIFF. Nobody would ever record in MP4 on a production camera, for any form of production work. Unless fast-paced "fast food" aka quick and dirty, not close to professional looking. EXR also offer the possibility to re-master projects (all exported frames) without re-rendering, among endless of other advantages. TIFF has its own set of advantages as well.

boxfx wrote: Overall it depends on the nature and turnaround time of your projects.

Absolutely. The aforementioned does join what is written here. It always depend on various factors and variables. Yet, none are valid for PNG.

@boxfx

Thanks for your insights, I had the same expereinces (mostly at least) but in the last couple of months I heard quiete some time how much wrong we, supposedly, are doing.

@elsksa

Thanks for taking the time to go over my post.

EXR or TIFF, all the way. PNG has been proven to be inappropriate in various cases. It's a spread of misinformation to write such claim.
However, there is a nuance between "there are no issues" and "it hasn't yet been noticed". Issues are undeniably occurring by the nature of the workflow (specifically that file format) and its many limitations. As the post does mention, it is simply inappropriate for being a "production" file format, one that will encode and contain various forms of data that will be handled in post.

But why? Can you give any examples where .png fails so hard?

In-renderer finishing is acceptable for preview purposes but simply not feasible for any post-work requirements (implying, integer file formats).

Well, I get that when working in VFX and compositing with live action footage. But we mostly work in the filed of motion design, so I see no problem achieving the desired result already in render. If theres no more need than a slight curve adjustment and some other minor tweaks, I don't see the massive benefits of not baking the color profile.

This tells me you haven't consulted the whole page! If AE is slow with any EXR variants, it's an AE issue, not necessarily EXR (I'm speculating, as I don't have AE). PNG has disappointing performance and, as a reminder, was never designed for CGI or professional digital imaging applications, while EXR have been, joined by a few others.

This wasn't an .exr bash. We know that it's AE fault but for now, we won't make the switch to another compositing package so the slow speed is a problem.
BUT: I did some testing yesterday and though we already knew .png was slow, I was suprised HOW slow. Plus, the new AE Beta handles the aces conversion very well and maintains quiete a lot of speed. In the current version, applying the ACES conversion almost triples the render time.

I've got a whole page coming up about "alpha" as I see many people confused about it, the workflow. Many will be surprised but I've spoiled some of it already across other pages and this forum. A good starting point would be to encode transparency via EXR or TIFF. Anything to avoid PNG will be beneficial and the right path.

I found out myself that you have to switch the premultiply alpha option in the octane dialoge. But again, tiff and png looks axactly the same (example was high dof on alpha).

We decided to stick to .tiff 16 bit with baked ACES with no compression since it delivers great speed, though 35% more disk space. As soon as AE comes out of beta we gonna try .exr and see how it behaves in terms of speed.

Elsksa, with all due respect you are doing nothing but pushing your preferred workflow as "correct" and anything else as wrong. I see you do this every few posts and in virtually every blog post you write. The technical detail of which you write are technically correct (the best kind of correct) and I respect your knowledge, but you are simply ignoring the real world limitations of production timelines.

You claim png is inappropriate and that tiff is preferable. It really, really, really isn't. Both give me the 8/16 bits of standard dynamic range colour data we need with no measurable difference in image quality. They both provide alpha channels. And png does it at a fraction of the file size at the expense of file saving time. If we were to switch from png to tiff, all we would end up with is the same image quality as we started with and larger files filling up our drives.

png wasnt designed for professional production use. Right, and DJI hobby drones weren't designed to drop weapons in war zones, but you make the most of what you have at your disposal and use the tools which do the task most efficiently. png files are quicker to work with than tiffs and look the same. QED, they are the better choice for many people when they don't have the time or inclination to work in un-graded floating point formats and workflows.

It seems your general point of view is that nobody could possibly get the image correct during rendering, during the photo shoot, or during recording, and that everything needs to be re-graded in post to get professional looking results. I dare say that if you can't get it looking how you want during the shoot/rendering then you perhaps are using post production as a crutch to try and fix bad renders.

boxfx wrote:I dare say that if you can't get it looking how you want during the shoot/rendering then you perhaps are using post production as a crutch to try and fix bad renders.

This is one of the best, true quote that I read. I will save it in my notebook

boxfx wrote:Elsksa, with all due respect you are doing nothing but pushing your preferred workflow as "correct" and anything else as wrong (...) you are simply ignoring the real world limitations of production timelines.

Nothing more wrong but to think that subjectivity took part in my writing. It is purely technically factual and I've shared numerous unassailable arguments. Free time is not on my side, demos will eventually come at a later point. Anyone capable could test it on their own and realize that PNG, as “worshipped” on online social posts and misinforming tutorials, is nothing but a wide-spread erroneous misconception. To use your own words: you are simply ignoring the technical and factual information. Feel free to compare PNG technical specifications to TIFF and EXR or produce technical tests and measurements.

boxfx wrote: You claim png is inappropriate and that tiff is preferable. It really, really, really isn't. Both give me the 8/16 bits of standard dynamic range colour data we need with no measurable difference in image quality. They both provide alpha channels. And png does it at a fraction of the file size at the expense of file saving time. If we were to switch from png to tiff, all we would end up with is the same image quality as we started with and larger files filling up our drives.

Quite the fallacy. I don't claim anything, as repeatdly said, it's all facts. In addition to that, PNG has the infamous"associated alpha" that is literally non-viable for compositing. At this point, it is becoming **alarming** that this trashy worthless file format is still naively being used for no valid reasons in such context.
TIFF has the proper transparency encoding, tags and more, such as optional compressions and tiled, making it the closest EXR alternative in term of viability, usability and flexibility, which (Mip mapping) will eventually come to Octane and is presently available in some other renderers.
EXR additionally also has the options to produce the most lightweight files of the bunch among other benefits that I've listed. Again and again and again, plain facts that anyone can demonstrate with know-how. Anyone opposing to all of this is simply in a complete delusion or misapprehension.

boxfx wrote: png wasnt designed for professional production use. Right, and DJI hobby drones weren't designed to drop weapons in war zones, but you make the most of what you have at your disposal and use the tools which do the task most efficiently. png files are quicker to work with than tiffs and look the same. QED, they are the better choice for many people when they don't have the time or inclination to work in un-graded floating point formats and workflows.

TIFF and EXR are at everyone disposal. It’s 2023. Barely anything can be done with a PNG file. The sole use-case that I can think of is logos/icons on a website when other file formats are not supported. Even a preview or web-ready image would be a JPG, certainly not PNG. Never. Ever. Performance and file weight also take a hit on the web. It's such a futile file format, people don't realize and keep being in pure denial.
PNG is (and better be) forbidden in small to large companies or by some self-aware individuals that do not neglect it.
Storage is not that expensive these days compared to years ago. If people do not have the appropriate storage solution for their data-consuming work, the problem is obviously not the file format, still frame or sequence rendering.
People have been storing important files on desktop/documents locations on Windows OS folders with no back-up and archivale solutions, omitting proper nomenclature and then getting surprised by some system/ software errors. Still happening. No excuses, even for the sole individual freelancer. People will learn from their mistake, soon or later.

boxfx wrote: It seems your general point of view is that nobody could possibly get the image correct during rendering, during the photo shoot, or during recording, and that everything needs to be re-graded in post to get professional looking results. I dare say that if you can't get it looking how you want during the shoot/rendering then you perhaps are using post production as a crutch to try and fix bad renders.

Conjecture.
You've certainly misunderstood my messages and led to wrong assumptions that would have been best kept for yourself. I've even been emphasizing it in other places, on the importance of "getting in right" in the renderer rather than relying on post. I apply this to myself.

However, it isn’t applicable to all cases. For instance, a digital camera is not only containing a manufacturer-subjective image-formation but the sole one. No other way. FYI, not a single digital still cameras can output the viewable imagery that can be properly developed in post from the raw sensor data. Period.
Renderers will inevitably produce a broken imagery without OCIO which without it, has no viable paths. No LUT or some sort of “color tools” built into the frame buffer GUI do. Needless to mention that “in-render correctness” is still relevant, prior to the image formation, which many omit.

To conclude, it seems that I have to get back to writing, update the initially posted page and publish the others. Just to be clear here, the problem is not the (proper) file formats or hardware, but disoriented people lacking awareness.

None of the replies have been taken personally in the offending sense, in case someone thinks otherwise.

I have a folder with 100 product render stills. I need to watermark them and convert them to jpg so I can upload them to the client approval and feedback system. I open photoshop, I run the usual File > Scripts > image processor tool so I don't have to sit there like a donkey opening and saving them one by one. I select my folder with 100 exr files and hit run.

Photoshop crashes every time.

This is what Im talking about when I say that you're ignoring the real world usage of these files. Yes, its a lovely format, coded by angels on gold plated keyboards. But it crashes photoshop every time we try to so much as open a file, let alone do anything further with it. Not the file format's fault, I know. A problem caused by shoddy programmers at Adobe, I know. But it doesn't change the fact that the superior file format is one of the least robustly supported formats across common editing tools.

boxfx wrote:I have a folder with 100 product render stills.

1, 100 or 100 000 doesn't make much of a difference for post.

boxfx wrote: I need to watermark them and convert them to jpg so I can upload them to the client approval and feedback system. I open photoshop, I run the usual File > Scripts > image processor tool so I don't have to sit there like a donkey opening and saving them one by one. I select my folder with 100 exr files and hit run.

Never ever one should do such a repetitive task. In any production environment, if automation is possible, it is the way. Fusion, which is the most recommended and affordable alternative to Nuke, can do this and a bunch more, without scripting, despite supporting scripts.

boxfx wrote: Photoshop crashes every time.

Because, ad nauseam, it isn't purposed for that.

boxfx wrote: This is what Im talking about when I say that you're ignoring the real world usage of these files. Yes, its a lovely format, coded by angels on gold plated keyboards. But it crashes photoshop every time we try to so much as open a file, let alone do anything further with it. Not the file format's fault, I know. A problem caused by shoddy programmers at Adobe, I know. But it doesn't change the fact that the superior file format is one of the least robustly supported formats across common editing tools.

Don't get me wrong. I absolutely see where you are coming from.
Software development is PITA for everyone and every piece of software. However, OpenEXR is widely supported on the widely used production software (plural). Affinity Photo, while not recommended, does support it with a relatively reliable stability, as far as I know.

This all makes me think that it is a sort of "fear of change" matter more than anything else. Give (all of you) a go at Fusion or Nuke. It's really not as complicated as one may think. The most basic tasks are quite similar in every post software. It's a lot more powerful than Adobe software, designed for what everyone does on this forum and not only more appropriate but robust.