OpenEXR Integration with Renderelements in newer builds

[instinct]

i started investigating max's rla.cpp to get some starting points....and while it's not really getting me kicked off so far it sure is fun to read the comments :

// Chromaticities of red, green and blue primaries and the white point.
// What the hell is this used for? Put in the suggested, NTSC, defaults.

So i'm not the only one that's lost sometimes :P

Thorsten

[instinct]

good news....i misunderstand the reading and writing docs it seems...as i dived deeper into the technical descriptions of OpenEXR i found :

Pixels in an OpenEXR file can be stored either as scan lines or as tiles. Tiled image files allow
random-access to rectangular sub-regions of an image. Multiple versions of a tiled image, each with a
different resolution, can be stored in a single multiresolution OpenEXR file.

So openEXR can be used in a similar fasion as vrimg (rectangular sub-regions = buckets )

[vlado]

So openEXR can be used in a similar fasion as vrimg (rectangular sub-regions = buckets )

So it seems, yes Will have to look into this at one point.

As for the object masks etc, you can try the PSD exporter plugin for 3dsmax (psdmanager or something), it uses the G-Buffer layers to exract different object into different photoshop layers and does that quite effectively.

Best regards,
Vlado

[studioDIM]

As for the object masks etc, you can try the PSD exporter plugin for 3dsmax (psdmanager or something), it uses the G-Buffer layers to exract different object into different photoshop layers and does that quite effectively.

Geez, the more i read, the more i get lost.
What are you talking about here, Vlado?
PSD layer writing aside, it does split objects one per layer?
And how has that go to do with the RPF layers?
Are you saying it does a better job than simply rendernodeID picking in combustion?
Or that it does the same as using RPF layers to clean up subpixel detail, but automatically?
I can feel a DUH! moment coming my way fast, here

Lele

[instinct]

the subpixel calculations could also be done in an OpenEXR writer BitmapIO. Before saving one could simply multiply rendernode rgb representation channels with coverage to get a filtered result. As it is an integer channel one could even go ahead and split things into seperate OpenEXR Channels (or maybe even use a tiled OpenEXR and save them as multiple levels of one channel?) Another thing that can greatly reduce size in OpenEXRs is cropped saving. I dont think that the splutterfish plugin does that. Basically you tell the EXR your final output size, and also tell it a frame within, that contains actual information. So when saving for example a beauty layer of a main element that is like a quarter of your view, you can save incredible amounts of disc-space by ignoring empty parts of the image and yet get all you need.

Thorsten