# Add "deepRaster" as allowable UsdRenderProduct.productType?

**URL:** <https://forum.aousd.org/t/add-deepraster-as-allowable-usdrenderproduct-producttype/1448>\
**Category:** USD\
**Created:** [April 16, 2024, 10:31pm UTC](https://forum.aousd.org/t/add-deepraster-as-allowable-usdrenderproduct-producttype/1448 "2024-04-16T22:31:45Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![spiff](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/spiff/32/22_2.png) [@spiff](https://forum.aousd.org/u/spiff)\
**Post date:** [April 16, 2024, 10:31pm UTC](https://forum.aousd.org/t/add-deepraster-as-allowable-usdrenderproduct-producttype/1448/1 "2024-04-16T22:31:45Z")

</div>

Hi all,  
We’re trying to get support for deep exr’s working in our HdPrman pipeline, and are hopeful there’s a way to start on a path for common support among renderers.

So instead of adding an attribute to name a specific RenderMan “display driver”, we’d like to add (and formalize, using `allowedTokens`) an additional option to `raster` for the UsdRenderProduct.productType attribute called `deepRaster` . It would be up to each renderer implementation to:

1. Provide a default behavior for what that means, specifically, and if it doesn’t support any deep output, either just produce a simple raster, or error(?)
2. Provide a renderer-specific auto-apply API schema for RenderProduct that adds any needed additional configuration properties for the renderer’s deep image support.

Then at some point in the rosy future, we could circle back and see if there are any common configuration properties that might make sense to loft into “generic” RenderProduct.

Any immediate concerns or thoughts?

---

<div class="post-metadata">

**Author:** ![mtucker](https://avatars.discourse-cdn.com/v4/letter/m/54ee81/32.png) [@mtucker](https://forum.aousd.org/u/mtucker)\
**Post date:** [April 17, 2024, 3:07pm UTC](https://forum.aousd.org/t/add-deepraster-as-allowable-usdrenderproduct-producttype/1448/2 "2024-04-17T15:07:25Z")

</div>

No concerns from SideFX. This would require no changes to husk, and a trivial change to karma to support this new productType value. We do have a few custom attributes that get attached to the render product to describe the deep image generation, but we have not wrapped them into an API schema (but obviously we could if that becomes beneficial).

Where this could be actually beneficial is in the LOP space, where we could use this standardization as an opportunity to provide better generic tooling. For example we could create a dedicated “Deep Raster Render Product” LOP node that adds per-renderer parameters at run time based on the API schemas each renderer associates with this product type.

The rosy future is obviously another matter, and we would be happy to participate in any effort to standardize this as much as possible.

---

<div class="post-metadata">

**Author:** ![BigRoyNL](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/bigroynl/32/413_2.png) [@BigRoyNL](https://forum.aousd.org/u/BigRoyNL)\
**Post date:** [April 17, 2024, 5:36pm UTC](https://forum.aousd.org/t/add-deepraster-as-allowable-usdrenderproduct-producttype/1448/3 "2024-04-17T17:36:03Z")

</div>

> [@mtucker](#):
>
> We do have a few custom attributes that get attached to the render product to describe the deep image generation, but we have not wrapped them into an API schema (but obviously we could if that becomes beneficial).

Could you elaborate on what those custom attributes are? Are those _very specific_ to karma? Or do you feel like they might be very common to deep image generation in general? Like - is the `deepRaster` product type sufficient for the needs to indeed be a generalized standards - or are we still lacking crucial data?

> [@mtucker](#):
>
> For example we could create a dedicated “Deep Raster Render Product” LOP node that adds per-renderer parameters at run time based on the API schemas each renderer associates with this product type.

Still knowing little about the intricate details of schemas (especially ‘auto-apply schemas’?) would the `UsdRenderProduct.productType = deepRaster` value be sufficient for API schemas to do this for each renderer correctly?

That may be a bit of an off-topic question if that should be _general knowledge_. Was just curious how that works for e.g. in LOPs to distinguish these behaviors, etc.

---

<div class="post-metadata">

**Author:** ![spiff](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/spiff/32/22_2.png) [@spiff](https://forum.aousd.org/u/spiff)\
**Post date:** [April 17, 2024, 6:09pm UTC](https://forum.aousd.org/t/add-deepraster-as-allowable-usdrenderproduct-producttype/1448/4 "2024-04-17T18:09:36Z")

</div>

First, an apology - I mis-spoke saying a MyRendererDeepRasterAPI schema would be auto-apply: you probably only want it to be applied when you **are** doing a deep image - different params would be relevant with different product types, and “application of API schemas” is currently the only mechanism we have in USD for configuring sets of relevant parameters (though higher-level logic like LOPs with their own params can, as Mark said, do that, too).

As to standardization… speaking with only shallow knowledge myself, it seems like there could be both renderer-differences and output-format differences that would need to be discussed and resolved in coming to a standard. II think that would be a worthy effort, but we’re not prepared to lead it right now 🙂

---

<div class="post-metadata">

**Author:** ![mtucker](https://avatars.discourse-cdn.com/v4/letter/m/54ee81/32.png) [@mtucker](https://forum.aousd.org/u/mtucker)\
**Post date:** [April 30, 2024, 5:55pm UTC](https://forum.aousd.org/t/add-deepraster-as-allowable-usdrenderproduct-producttype/1448/5 "2024-04-30T17:55:14Z")

</div>

We have `karma:product:dcmCompression`, `karma:product:dcmOfSize`, and `karma:product:dcmzbias`. I also don’t know very much about deep images so I don’t know exactly what these all mean, nor if they are likely to be “common” across renderers. But we would certainly be interested if there is any kind of standardization effort.
