EXR multilayer troubles

Hello everyone. I’m getting some EXRs from CG. I import it into batch and the beauty is fine, but the AOV’s contain a lot of black frames. In nuke it reads fine, and if I run it through nuke Flame reads it fine. if I tell Flame to view as frames not sequence all the frames look good. Any Ideas. Thanks in advance.

Send the frames to support. Stephane’s team deals with file I/O.
@Slabrie

1 Like

As usual (well, most of the time) Alan is right! Please open a support ticket and we will have a look at the files and find the issue.

1 Like

Thanks guys.

Case number 20308903

It’s worth checking display window vs data window on import, that might be a fix or a gotcha.

Thanks Miles for open a support ticket! When opening a ticket, make sure to provide our support team the link on the conversation on Logik so we can link them together. Often, it is hard to see the relationship between a discussion here and an entry in our bug tracking system.

Same applies when you fill in a Genenal Improvement on Flame Feedback.

1 Like

Hi… did this ever get resolved? I am having the same issue. It seems the AOV’s dont have the same embedded metadata as the RGBA so I get 10000+ frms of black before the footage starts on all AOV’s… Would love to know how to solve this? Thanks

From what I remember from the original issue, not all AOV had been generated for all the frames in the sequence. If you have all frames rendered with the same AOV you should be fine.

Hi… thanks. My rgb frame range for the seq and all AOVs are the same, it just keeps adding 1000’s of frames of black at the head of the import into flame.
We’ve had it across several jobs across several ops …
we were wondering if anyone had found the same issue and ideally a solution ?
Many thanks

Hello timo!

I don’t think your issue is the same as Miles. I guess you might be using Open Clip or Pattern Browsing and that a version of the renders have a different start timecode as the first version. Could you validate that?

@miles have you been able to narrow down the issue? from what we have seen in the files you have provided to our Support team, some AOV were not generated for all frames in the sequence and this is why Flame is showing black frame for the AOV that have not been generated. It is not clear for us why the 3D render did not generate the AOV for all frames. Maybe this is a use error?

hi… Using Open clip pattern browsing yes. so we can update versions from Nuke.
If we have a clip of say 89frms… when you import from Nuke you often get 1000’s of black frames then 89 frames of media. Its as soon as you get AOV’s involved. Metadata all fine on the RGBA but once AOVs get used the flame struggles.
Thanks

Looking at the media files we got from Support, it seems that the for Multi Part OpenEXR, the name of the part is changing over time for the same AOV! As an example, I see in the files that subimage03_GI becomes subimage03_DifuseFilter in the next frame! So, they issue is related to changing part name for AOV. Not sure how this can happen when one renders CG. Is it possible that frames have been overwriten for updates AND that the rendering settings have been changed?

1 Like

Hey mate. No. It’s not a renderer issue either because Nuke as no problem reading all of the AOVs from the file.

Sorry to contradict you but if you were to compare the original files and the one from Nuke (i.e. using MediaHub / Frame view) you would see that the Name of the parts do not match between the various frames of the file sequence. When Nuke recreated new EXR it got rid of the original EXR part name and used a matching data for all frames (which seems to be the name of the top folder) and this is why you can see the right data in Flame. Obviously, I recreated the files in Nuke also and saw this behavior.

To better understand the issue, import three frames form your file sequence in Batch (with MediaHub set to Frame Mode) and expand the channels and you will see the issue while looking at the available channels. Since Flame reads the part + AOV and does a mapping to the Clip node, since the part name for given AOV is changing over time, this is why you see black frames.

We will have a look if we could provide a way to ignore the part name like Nuke does. But we will probably also ask our friends at Maxon since there documentation does not show a way to change the name of the part when rendering. This is why I suspected a re-render of some of the frames but that would surprise me if the CG artist would have done that. But, hey! we are in 2023, everything can happen (and will! :wink:

The issue can also be seen if you use the exrheader command line tool from the OpenEXR SDK and list the metadata of the files in your sequence.

1 Like

Excellent. Thanks for the deep dive. As long as it works. I’m happy.

Hey @miles

I am getting the same issue and i have an open case with support.

Good day.The dev saw the issue and here’s what they think after initial investigation:There are many issues with this content which seems to be related to how the rendered generated the AOV. It is like the 3D artist re-rendered single frame in the sequence AND either modified naming OR did not render the same AOV as the first frame of the sequence.
If you import as single frame the 5 frames of the EXR sequence, you will see that the amount of AOV is not the same between the five frames so that explains the issue. if there is no data for a given AOV then we show black.
Importing the EXR in Nuke and rendering out new EXR showed me that Nuke does not read the prefix and only use the AOV name so this is why there is no issue in Nuke with this content AND that generating new EXR fixes the issue. FLME-63769 AOVs in a Multi Layered EXR will flicker in Flame

I was wondering if your CG dept were using deadline to render :thinking:

We had a deeper look at the issue and reported the problem to Maxon but they have no clue why the name of the parts in the EXR generated by Redshift has changed for the same AOV in a render. We will provide a way to bypass this issue in an upcoming Update of Flame Family products and I will keep you updated on when this will be available.

Thanks for opening a support ticket with media files! This helps us tremendously.

1 Like

As discussed in last Sunday 024.1 Update Logik Live, we have added a workaround for this issue in the OpenEXR Format Options so one could get the right frame. am closly working with Maxion / Redshift team to find where the issue is and the files I get from them have no issue. The part / AOV are all matching for all frames in a sequence. @miles / @PlaceYourBetts we will need to know more about how the files have been generated. Only the EXR is not enough to narrow down the issue. Could you get to your 3D partners and get the version of the DCC, Redshift version, OS, render queue, etc?

2 Likes

Hey @Slabrie

Thanks for looking further into this and thanks for the fix offered in 2024.1

We were using maya 2020.4 with redshift 3.0.65, on windows 10 pro 10.0.19044 build 19044 (not sure if we have updated since, probably less important). We are using deadline 10.1.23.6 for rendering.