Open EXR support

[dr_plugger]

Hi,

Could someone fix the OpenEXR reader. If you read an image in with an embedded DOD / ROI it is completely ignored and only the image data is considered. The reader should take note of the display window too.

Many thanks in advance

Piotr

[marcop]

Could you email one of these OpenEXR images that has an embedded ROI to sfxsupport@silhouettefx.com?

[jbills]

amen. I've sent a few of these over, but can't say I've ever heard back that you guys understand the problem (not being critical, just sayin'...). do you need more?

we've fixed this with a custom reader, but even after fixing this problem, paint doesn't work with EXRs. as evident when you try to clone an EXR with alpha. try it and watch the fun. hopefully this will be on the radar for the next update?

[marcop]

We have fixed a bug in the upcoming 2.3 release that had to do with premultiplication in EXR files when rendering as well as EXR's with alpha channels. I can now properly render RGBA EXR's as well as paint on RGBA EXR's.

J, you prevousily sent an EXR with a DOD embedded. It was a shot of some CG tires. I loaded this frame into Silhouette, After Effects, Fusiotn 5 and Shake. Fusion would not load the file at all. After Effects and Silhouette both loaded only the cropped area of the DOD which was 1244x359. Shake was the only one that could load the DOD. Silhouette's behaviour is consistent with other programs that don't support DOD.Since we don't have DOD capability at this time, this functionality most likely have to wait until we have DOD. We are looking at DOD for the 3.0 release. It is quite involved and will modify many areas of the program. We realize the importance of DOD and wouild like to do it.

[jbills]

that's great news about the improved EXR support! can't get our hands on that soon enough. Silhouette is one of the few non-conformists left in our pipeline.

DOD support would be great, but in the meantime just interpreting the existing image data correctly into the frame would do the job. if DOD support doesn't make it into 3.0, please give me a heads up - at the very least I can help get your exr importer up to speed so it maps these pixels correctly into the full frame.

[marcop]

The existing image data is correctly interpreted into the frame with the existing 2.2 release build. I took you Tire example, loaded it into Silhouette and saved it out. I comped it over the original frame in Shake and it matched perfectly. Maybe in an earlier version of Silhouette, this was busted, but it is working now.

[jbills]

hmmmm - I don't get the same results?

Probably just a simple misunderstanding of our EXR workflow. Let me take another crack at explaining what's wrong.

An EXR with 508x332 image data will open up fine in silhouette at 508x332, but that's not the problem. That's not how we view or work with EXRs.

The problem is when you try to bring it into a 2k session, it stretches to fill the frame so your little 508x332 is now mapped to 2048x1556. I think that's what's being misunderstood? We work at 2k, not 508x332. Please understand I'm not so concerned with how other software handles it, I'm only concerned with how you handle it, because we use you.

So, what's important to get here is that we're using these EXRs in conjunction with 2k plates, sometimes loading both into FG/BG and using one as reference for the other.

Also understand that sometimes we need EXR info to extend outside the frame, so it's conceivable to have a 3096x555325 EXR inside a 2k session.

Finally, realize that I've only sent you a single frame, but imagine if the t(y)ires in that sample shot I sent you were heading towards the camera. Well, they'd get bigger in the frame, wouldn't they? so that 508x332 t(y)ire would be 1900x1056 on frame 6. And how do you expect Silhouette to deal with that if you're working in a 508x332 session?

Hopefully this is starting to make some sense.

like I said, we dropped the resources to have an importer written. If you've got RGBA working, then most likely we'll finally be able to use Silhoeutte on EXRs. Ready to test anytime. :)

[marcop]

I undertsand what you are trying to do.

A couple of things:
- I was trying to respond to your initial email where you said that Silhouette was distorting the DOD poortion of the 1920x1080 image that you sent. My point was that Silhouette succesfully loaded the DOD portion at it's cropped resolution without distorting it.

- Silhouette will fit the source image to the Session resolution, so yes, you will see distortion if the source plate is a different aspect ratio.

- Without DOD functionailty in Silhouette, we will most liekly not be able to do anything you are asking for in terms of supporting static or animated DOD's in source EXR frames.

- We are trying some issues with a new licensing system before the new builds are sent. Hopefuly, it wonlt be too much longer.:)

[dr_plugger]

Hi,

I'll email you an image to the stated address, but if you have shake, then all you have to do is to get a colour wheel, set the width and height params to 720, 486 respectively and save it as an exr - the shake exr writer will embedd the correct DOD.
thus:
> shake -colorwheel 720 486 4 -fo colwheel.exr
> exrInfo colwheel.exr
colwheel.exr:

file format version: 2
channels (type chlist):
A, 16-bit floating-point, sampling 1 1
B, 16-bit floating-point, sampling 1 1
G, 16-bit floating-point, sampling 1 1
R, 16-bit floating-point, sampling 1 1
compression (type compression): piz
dataWindow (type box2i): (117 0) - (602 485)
displayWindow (type box2i): (0 0) - (719 485)
lineOrder (type lineOrder): decreasing y
pixelAspectRatio (type float): 1
screenWindowCenter (type v2f): (0 0)
screenWindowWidth (type float): 1


As far as the workflow is concerned, adding dod support to silhouette is a nice feature, but what is more important is how that image is read: you take the display window as the size of the image buffer, and you read in the data and place it at the 'right' location.

So, for the example of the colour wheel, Silhouette should import this as a 720x486 image and fill in the region outside of the data window with black pixels; then apply any pixel aspect ratio corrections.

This how I see tools without 'active' dod should support this as the DOD is really just a nice way of telling you where the data lies.

Hope you can do a 'fix' for this before 3.x

Many thanks in advance

Piotr

[jbills]

nice one, good doctor. :)

[paulm]

One thing we CAN do for 2.3 is to read the DOD into the correct portion of the 2k plate, rather than only loading the cropped portion at its reported DOD size. This is the "default" behavior of the EXR library, so I just need to make a few adjustments.

[paulm]

BTW - sorry I haven't chimed in sooner. I was taking an annual caving trip at Mammoth Cave in Kentucky.

[dr_plugger]

re the positioning ... that the one - that would help a great deal.

Thanks

Piotr

[dr_plugger]

btw - do you know where the the logConversion check box is there for me whilst absent for some of the other users - tks

[paulm]

That is an unused preference in an experimental build of the Cineon module. It isn't hooked up yet but will eventually provide a way of not doing ANY conversion to linear in the Cineon module.