How can one add a new color space to Blender?

[Mark_G]

I am fairly new to Blender (although I’m a 20-year veteran from a commercial 3D package that has been orphaned). I am amazed by Blender’s capabilities; but struggling a bit to get my arms around all the hidden options.

Much of my work is with a product line that features bright yellow packaging. If I am forced to work in sRGB color space, it is a constant battle to keep the yellow tones from going green. To look right, the yellows in these subjects must shade darker with magenta leading cyan (after separation). A bit too much blue and the packaging looks unacceptably drab.

Over the course of many years 3D work with this product line, I have found that working in 16-bit ProPhotoRGB for my image textures (converted directly from CMYK label print art) gives me the least trouble when separating my renders for commercial printing. My method is to set up my textures in ppRGB, import the texture allowing the program to assume they are sRGB, render my art and export with an sRGB profile; but assign ppRGB when importing the render into Photoshop. This works quite well.

My question is: Is there a way to get the ppRGB colorspace loaded into Blender so I can let Blender know that’s what I’m working in? That way, I can rely on Blender to transform the colors correctly on screen so I get a truer picture of what my art will look like when it gets to Photoshop. I could then also save it with the ppRGB profile embedded in it.

I can work “in the dark,” knowing that the colors will snap back “true” once I reprofile in Photoshop; but it would sure be nice to be able to see the colors correctly while still in Blender.

Any help will be appreciated.

[Eary_Chow]

Do you mean you need to import ProPhoto-RGB-encoded texture and export in PPRGB as well? Are you exporting the 3D render or just a compositor-graded version of the imported texture?

Also are you aware that upon import, Blender converts the texture from its source encoding (potentially PPRGB) to the working space Linear BT.709 I-D65 (I.E. Linear sRGB I-D65), so the RGB values in software is always Linear BT.709/sRGB?

You can add the colorspace by editing the OCIO config, the default config has reference space set to Linear BT.709, I would recommend adding a ProPhoto RGB standza, transform from reference Linear BT.709 to CIE XYZ I-D65 (the XYZ in default Blender has I-D65 white point), and then use I-D65 to I-D50 chromatic adaption, then transform to ProPhoto primaries. And then apply the transfer function, I searched online and it seems PPRGB has a piecewise function, but for simplicity’s sake I think we can just use power 1.8. So in the end have inverse exponent transform with value 1.8.

After adding the stanza, you are now able to import PPRGB encoded textures. But exporting to PPRGB maybe a bit tricky. Still doable though. I can type more if you also want to export in PPRGB.

I can help you more after I finish my work today. Now I need to go back to work.

[Eary_Chow]

Ok just quickly pulled together the stanza

  - !<ColorSpace>
    name: ProPhoto RGB
    family:
    equalitygroup:
    bitdepth: 32f
    description: |
      ProPhoto RGB Closed Domain Colorspace with Power 1.8 Transfer Function and D50 White Point
    isdata: false
    from_scene_reference: !<GroupTransform>
        children:
            - !<ColorSpaceTransform> {src: Linear, dst: XYZ}
            - !<MatrixTransform> {matrix: [1.0478112, 0.0228866, -0.0501270, 0, 0.0295424, 0.9904844, -0.0170491, 0, -0.0092345, 0.0150436, 0.7521316, 0, 0, 0, 0, 1]}
            - !<MatrixTransform> {matrix: [1.3459442150636944, -0.2556019658324881, -0.0511078391985947, 0, -0.5446049488130403, 1.5081764157993822, 0.0205264766660757, 0, 0.0000000000000000, 0.0000000000000000, 1.2118446405029910, 0, 0, 0, 0, 1]}
            - !<ExponentTransform> {value: 1.8, direction: inverse}

Might have missed something but at least for the moment I think this should do it.

Find your Blender’s config.ocio file and open it with any txt editor, find the colorspaces: section and copy & paste the above stanza in, then you have your ProPhoto RGB as texture import colorspace.

[Mark_G]

Hi, Eary,

Thank you so much for the quick response. Blender is amazingly capable, but the staggering range of options and different ways of accessing them are quite intimidating.

In answer to your question, yes. I would like to import ppRGB textures, render my models, and export still in ppRGB. The system I have worked with all these years was pretty much color space agnostic. They didn’t really let you peek under the hood and it didn’t profile the renders. The results were quite predictable as long as you used the same profile going in and reapplied it to your resulting renders.

The reason I settled on ppRGB is because it does the best job holding onto the nuances of color on the round trip from CMYK to RGB to CMYK. The subjects are products with CMYK-printed labeling, and my renders are going to printed in advertisements and marketing materials. The result has to look like the “real thing.” My source textures start as CMYK art; but, of course, I have to transform them into some form of RGB to work with them in 3D.

I was hoping there was a way to get Blender to hold onto the ppRGB color numbers all the way through. One color space, from a numbers perspective, is just the same as another (of the same bit depth). What those color numbers represent can be quite different based on the profile definitions. I had assumed that if I could get ppRGB as a menu option, I could tell Blender that I am working in that space and it would handle the conversion to the screen space so I could see my work in Blender accurately. That was the weak link in my old system. The package I was using was working in either sRGB or AdobeRGB (they wouldn’t say) and as a result, my colors looked drab and muted while displayed on the models. Once rendered, I could assign the correct profile in Photoshop and the same numbers that showed up as drab in the 3D program were bright and on target to give me a good CMYK separation for printing.

Given this more detailed description of what I’m after, is the code you have so generously written what I need to accomplish my goal? Or is there another piece that will need to be put in place?

Or is what I hoped to achieve even possible?

[Eary_Chow]

@Mark_G

I was hoping there was a way to get Blender to hold onto the ppRGB color numbers all the way through. One color space, from a numbers perspective

So first of all the imported non-exr texture most likely are not linear, like I posted above they likely have power 1.8 encoding or something close to that, while the working space in Blender always needs to be linear. So the values will change, at best you can have a Linear PPRGB working space, but the PPRGB texture will be linearized upon import so the values will change.

And I believe PPRGB primaries are outside of the spectral locus, which makes it a poor choice for light transport rendering. Any values outside of the locus are not colors, they are just mathmatic values that don’t make sense. If your goal is to cover more CMYK colors, I would suggest using Display P3, I believe P3 is large enough to cover most CYMK colors.

@Mark_G

The package I was using was working in either sRGB or AdobeRGB (they wouldn’t say) and as a result, my colors looked drab and muted while displayed on the models. Once rendered, I could assign the correct profile in Photoshop and the same numbers that showed up as drab in the 3D program were bright and on target to give me a good CMYK separation for printing.

There is one thing you need to realize, the rendering engines produce open domain (values from 0 to infinity) tristimulus data, and view transforms like Filmic or AgX etc. produce the end image from those data. No matter what you working space is, Filmic still forms your image in sRGB, without an alternative image formation tool, the best you can do is forming the image in sRGB and then convert it to your wider gamut color space of choice, but the formed image will still be limited to sRGB.

So TL;DR PPRGB has primaries outside of the locus so it is not ideal, better to use P3 that also covers most of the CMYK colors. And Filmic the image formation still only outputs sRGB, so exporting wider gamut render would not be possible as long as the image formation tool used is Filmic.

We are developing a Filmic upgrade, we plan to make the formation happen in P3 instead of sRGB, still working on it though.

[Mark_G]

I appreciate you taking the time to address this for me.

The reason I have preferred ppRGB is because, of all of the RGB color spaces available to me in Photoshop, it is the only one that can give me a clean golden yellow from an RGB image of the art I need to match. Even P3, when separating back to CMYK, pollutes the yellows with more cyan than magenta. I know many of the “colors” in the ppRGB space are not human perceivable colors at all; but they serve as “tent pegs” to anchor the space out beyond the limits of perception to allow the pure yellow I need to be achievable. The posterization this can generate would be a deal breaker if I wasn’t working in 16 and 32 bit. It is true I can work from and sRGB separation – but it involves much hands on color correction to every image to bring it back to true fidelity – something I’d rather avoid if possible. I generate a lot of images.

If Blender can take an OpenEXR linear image for the image map, I have tested and find that I can make them from the ppRGB file in Photoshop. It isn’t actually profiled any more, but I have tested it “round trip” and can read it back in to Photoshop, assign the ppRGB profile to it, and it comes back to its original colors. It even separates into a clean CMYK of my target values. If Blender can work with a linear OpenEXR texture map, and export the render as an OpenEXR, shouldn’t I be able to use Blender in the same way I was working in my previous program? Just re-assign the profile after the render is made?

The icing on the cake would be to have that ppRGB profile available in Blender to do the screen transform while working. If it can’t, I can just work like I used to: See the maps in ideal color as I prep them in Photoshop, apply them in the 3D program where they will look drab and desaturated, render the image, bring it back into Photoshop and re-assign the ppRGB profile to see the render in its ideal color.

[Eary_Chow]

@Mark_G

I know many of the “colors” in the ppRGB space are not human perceivable colors at all; but they serve as “tent pegs” to anchor the space out beyond the limits of perception to allow the pure yellow I need to be achievable.

Again those values outside of the locus are not “invisible colors”, they are just mathmatical result of the math projection. With PPRGB as working space, you can easily yield large portion of info outside of locus in your render.

The problem is that neither your screen nor your print can hold spectrally pure yellow. The CMYK yellow is already within P3 range.

What you see on the screen is in the end whatever your screen is capable of displaying. Image formations like Filmic or AgX take those values your end medium (monitor, print, etc.) cannot hold, and engineer it into an image that your medium can express.

@Mark_G

If Blender can take an OpenEXR linear image for the image map, I have tested and find that I can make them from the ppRGB file in Photoshop.

If you directly save EXR from render, Blender saves the pre-view-transform data, not the post-view-transform image. Meaning you need to do your own image formation afterwards. You can of course use the Convert Colorspace node in compositor to manually apply view transform, and save the formed image result to the EXR, but again Filmic outputs to sRGB. You can of course after the formation convert the result to PPRGB but the objective chromaticity will still be in sRGB.

But again, CMYK is not that large, neither is your monitor, even when you get your wider gamut render, how are you going to compress those data to your limited medium’s range? This is especially challenging because PPRGB has large portion outside of the locus, those values are none sense to begin with.

[Mark_G]

@Eary_Chow

The problem is that neither your screen nor your print can hold spectrally pure yellow. The CMYK yellow is already within P3 range.

I am not trying to attain spectrally pure yellow. I am trying to get an RGB “yellow” that will separate back out to a fairly pure CMYK yellow. I know this is attainable because I do it every day working with the ppRGB profile. However, it is not within P3’s range.

Perhaps I’m not making clear what I really need. I have to make imagery of products that are real world items printed with four-color process inks. The digital models are decorated with maps that are derived from the actual CMYK print art. The goal is to generate art from Blender that can be re-separated back into CMYK art to print advertisements depicting these products. Nothing in the original product is beyond the reach of CMYK printing. What is tricky is that CMYK and RGB gamuts do not completely overlap. The weakest points of each system are the primary colors of the other system. Hence, CMYK has a real problem with deeply saturated reds, greens and blues. RGB has trouble with pure cyans, magentas and yellows. While the larger gamut of ppRGB contains a lot of wasted pseudo-colors that are not perceivable colors at all, it does extend far enough in the yellow direction to get close to the color of process yellow printer’s ink. Yellow is the critical color in my work and so it is the best choice for me.

This is not theoretical. So I can show you the data, I ran the following test. I made a swatch of 0c 0m 100y 0k in Adobe Illustrator. I rasterized it directly into 16-bit RBG in the following profiles. I then separated them back into CMYK. This test shows how closely the actual color yellow represented on a printed label can be brought from a given RGB color space back to CMYK.

sRGB
0c 0m 100y 0k > 255r 241g 000b > 4c 1m 90y 0k

aRGB
0c 0m 100y 0k > 255r 241g 040b > 2c 1m 94y 1k

P3
0c 0m 100y 0k > 255r 242g 072b > 3c 1m 94y 1k

ppRGB
0c 0m 100y 0k > 238c 237g 073b > 1c 1m 92y 1k

As you can see, only ppRGB yields a yellow that doesn’t lean toward green. It doesn’t seem like much, but all of the yellow tones, including the deeper ones as the model is shaded by the lighting of the scene, trend toward greenish yellow.

@Eary_Chow

If you directly save EXR from render, Blender saves the pre-view-transform data, not the post-view-transform image. Meaning you need to do your own image formation afterwards.

This is what I want – the pre-transform data.

[lucas.coutin]

Considering that ProPhoto RGB is open source, download files from official site or git and replace files in C:\Program Files\Blender Foundation\Blender 3.3\3.3\datafiles\colormanagement (or equivalent path in Linux). If isn’t free you may find those files in Photoshop folders. Blender default colorspace (sRGB, Filmic, False Color) will be removed. Yet for CG, ACES is the standard for production, and you can export any colorspace that are open source. Works better using 32-bit mode, or softwares that have linear workflow. Blender instalation tutorial.

[Eary_Chow]

@Mark_G

P3
0c 0m 100y 0k > 255r 242g 072b > 3c 1m 94y 1k

It looks to me the conversion is wrong if this is the case?

Note PPRGB has a different white point, both sRGB (1, 1, 1) and Display P3 (1, 1, 1) means D65 chromaticity, but PPRGB’s (1, 1, 1) means D50 chromaticity. You need to make sure your conversion is not hardcoded D50 white point.

@Mark_G

This is what I want – the pre-transform data.

It seems you don’t quite understand. Pre-transform data contains crazily large values up to the thousands or even higher (I mean look at how bright Nishita Sky is), most traditional DCCs out there lack the ability to work with values this large. You certainly need to form the image with some view transform first (formed image would be from 0 to 1, float expression), then re-form the formed image in CMYK.

At any rate, I already provided you with ProPhoto RGB’s stanza:

Linear version for working space:

  - !<ColorSpace>
    name: Linear ProPhoto RGB I-D50
    family:
    equalitygroup:
    bitdepth: 32f
    description: |
      Open Domain Linear ProPhoto RGB Tristimulus with I-D50 white point
    isdata: false
    from_scene_reference: !<GroupTransform>
        children:
            - !<ColorSpaceTransform> {src: Linear, dst: XYZ}
            - !<MatrixTransform> {matrix: [1.0478112, 0.0228866, -0.0501270, 0, 0.0295424, 0.9904844, -0.0170491, 0, -0.0092345, 0.0150436, 0.7521316, 0, 0, 0, 0, 1]}
            - !<MatrixTransform> {matrix: [1.3459442150636944, -0.2556019658324881, -0.0511078391985947, 0, -0.5446049488130403, 1.5081764157993822, 0.0205264766660757, 0, 0.0000000000000000, 0.0000000000000000, 1.2118446405029910, 0, 0, 0, 0, 1]}

Below is power 1.8 version for texture import and color picker.

  - !<ColorSpace>
    name: ProPhoto RGB 1.8 I-D50
    family: Displays/SDR
    equalitygroup: ""
    bitdepth: unknown
    description: ProPhoto RGB Closed Domain Colorspace with Power 1.8 Transfer Function and I-D50 White Point
    isdata: false
    allocation: uniform
    from_scene_reference: !<GroupTransform>
      children:
            - !<ColorSpaceTransform> {src: Linear, dst: Linear ProPhoto RGB I-D50}
            - !<ExponentTransform> {value: 1.8, direction: inverse}

Then you can set the scene_linear role to be your linear working space, the color_picking role to the 1.8 version of PPRGB. And done, you can import PPRGB and render in linear PPRGB, you can export EXR in Linear PPRGB, but note the end formed image out of Filmic is still sRGB.

With that said, I still believe it is wiser to not use any colorspace that has primaries outside of locus as working space. If you want a largest space possible. I advice using BT.2020. But note you will have a large amount of info you cannot express in CMYK, just like PPRGB, but better than PPRGB is that BT.2020 are all actual colors.

Here is Linear BT.2020 Stanza:

- !<ColorSpace>
    name: Linear BT.2020 I-D65
    family: Colourspaces
    equalitygroup: ""
    bitdepth: 32f
    description: Open Domain Linear BT.2020 Tristimulus with I-D65 white point
    isdata: false
    allocation: uniform
    from_scene_reference: !<GroupTransform>
      children:
            - !<ColorSpaceTransform> {src: Linear, dst: XYZ}
            - !<MatrixTransform> {matrix: [ 1.7166634277958805, -0.3556733197301399, -0.2533680878902478, 0, -0.6666738361988869, 1.6164557398246981, 0.0157682970961337, 0, 0.0176424817849772, -0.0427769763827532, 0.9422432810184308, 0, 0, 0, 0, 1]}

Here is Power 2.4 version of BT.2020 for texture import:

  - !<ColorSpace>
    name: BT.2020 2.4
    aliases: [BT.2020, BT.2020 2.4 I-D65]
    family: Displays/SDR
    equalitygroup: ""
    bitdepth: unknown
    description: BT.2020 2.4 Exponent EOTF Display
    isdata: false
    allocation: uniform
    from_scene_reference: !<GroupTransform>
      children:
            - !<ColorSpaceTransform> {src: Linear, dst: Linear BT.2020 I-D65}
            - !<ExponentTransform> {value: 2.4, direction: inverse}

Again, set linear verison as scene_linear role and 2.4 version as color_picking and done.

But good luck in handling all these wide gamut info that CMYK cannot express.

Also remember to double check your conversion tool, does it hardcode D50 white point? If it does, you can adapt P3 values to D50 first before doing the CMYK conversion.

[Mark_G]

ppRGB’s different white point may explain why it can give me an RGB yellow that can successfully be separated back into a decent CMYK yellow, rather than a greenish one. Every RGB space I have available to me in Photoshop pollutes yellow with extraneous cyan except ppRGB. The worst offender is sRGB.

The conversion figures I gave you are correct. Perhaps you don’t understand what they represent. Those are the values that Photoshop renders a CMYK 100 yellow into each of the RGBs listed, and then the CMYK values that result when they are transformed back to CMYK. They demonstrate why ppRGB is the best space to work in for my specific print reproduction needs.

I know this is commercial print esoterica, and Blender, like all 3D systems deals only with additive primaries, rather than pigments; but it’s simply how I need to work. My art elements have to come from there and return there while matching well. I’ve been handling color separations for print for over 30 years and know how to take a less than optimal image and bring it back to the right colors. I’m just hoping to hammer out a Blender pipeline that will not require quite so much after-the-render adjustment.

Thank you for the additional code to try out. You have been most helpful and I will make use of what you’ve provided and report back how I make out.

[Mark_G]

Time for the promised update.

I have settled on a reliable method to get a 4C process original subject converted to a ppRGB image map in Photoshop; export it to Blender, render it and import it back into Photoshop with uncompromised ppRGB colors which separate into a reliable match for the 4C process original.

The only part of the process that is not ideal is that while the image map, or the resulting render, is visible on screen in Blender, it looks wrongly profiled. What I mean is that it looks just like a ppRGB image displayed with an sRGB profile assigned to it. Since ppRGB has a much larger gamut than sRGB, the colors look flat and drab if profiled with the smaller sRGB space. As a test, I took the same ppRGB image map in Photoshop and assigned (not converted) the sRGB profile to it. Compared to the same image mapped to a flatly lit polygon in Blender it looks identical.

With this method I can work in Blender in the same manner I have successfully worked for 20 years in my previous 3D package. I can’t see the true colors until I bring the render into Photoshop, and so I am in some ways “flying by instruments,” but since the results are predictable I can make do.

I will outline the exact method below. Thanks, Eary, for your patience in explaining how Blender deals with these things. I know this working method is not what you recommended, but the special requirements of the product renders I deal with makes it necessary for the time being.

I begin with art prepared for commercial printing. This is usually a label, carton or wrapper built in CMYK colors in Adobe Illustrator.

In Photoshop:

1. Rasterize AI file as 16-bit CMYK.
2. Convert to ProPhotoRGB.
3. Switch file to 32-bit (Linear).
4. Save as OpenEXR.

In Blender:

5. Import the image as a Material map, Color Space: Linear.
6. Compose and light your scene.
7. Make render; Scene Properties>Color Management:
   Display Device - sRGB, View Transform - Standard, Look - None.
8. Save render as OpenEXR, Float (full), Color Management: Follow Scene.

In Photoshop:

9. Open the render file, assign profile ProPhotoRGB.
10. Drop file down to 16-bit, Method: Exposure 0.00 and Gamma 1.00

You now have a ppRGB profiled file that will separate into CMYK with quite high fidelity to the source images maps you began with. Of course, the effects of variations in lighting, source light colors, reflected colors and all the issues we deal with in real life product photography still apply. But this workflow doesn’t add an extra burden from avoidable color distortion during the trip to an RGB colorspace and back.

Now a few words as to how I am guessing this is working. I hope Eary or someone else with a deep understanding of Blender and color can either confirm this explanation, clarify it, or point out where it is wrong:

Even though the source of the OpenEXR file is a ppRGB file, once it is converted to OpenEXR it is either no longer profiled at all, or is converted into whatever Linear color space the OpenEXR standard is based on. Bringing it in to Blender as an OpenEXR and setting the space to merely “Linear,” then later rendering and saving it out as an OpenEXR puts me back where I started: Photoshop reimporting the OpenEXR format directly into ppRGB with whatever conversion it used to export it originally, reversed. The “magic ingredient” is that OpenEXR handles the colors with enough fidelity that it isn’t introducing much distortion on the round trip. Once back in Photoshop as ppRGB, the separation to CMYK is handled with the same fidelity as ppRGB usually provides.

I still think there may be some way to have Blender re-profile the screen representation in the material properties and render windows. I have tried some of the code provided in the thread above, but I’m not sure I am using it correctly. I have added all three ppRGB profiles that Eary provided, but none of them seem to allow the map to be depicted on screen in a way that matches how the properly profiled version in Photoshop looks. When applied to the map, the plain Linear looks like the sRGB profile is applied. All three of the new ppRGB profiles make it look overly saturated. The closest profile anywhere in Blender is the Linear ACEScg, but it is just a little more saturated looking.

The main issue is, while plain Linear looks as if mis-profiled as sRGB, it renders out and reimports into Photoshop perfectly. Every one of the other new profiles changes the renders in the same way it changes the screen depiction. I don’t need to change anything but the way the map (and render) is depicted while on screen in Blender. Is there a way to alter the screen representation of a map without changing the resulting render?

If this isn’t possible, I can live with it.

[Eary_Chow]

@Mark_G

Convert to ProPhotoRGB.

@Mark_G

Save as OpenEXR.

@Mark_G

Import the image as a Material map, Color Space: Linear.

By doing this, you saved the EXR in PPRGB, but in Blender interpreted the EXR as Linear Rec.709. Yes, the Linear option means Linear BT.709.

@Mark_G

Save render as OpenEXR, Float (full), Color Management: Follow Scene.

In default Blender, Follow Scene means save it as Linear BT.709, if you didn’t change the scene_linear role, that is.

@Mark_G

Open the render file, assign profile ProPhotoRGB.

If you did not change the scene_linear role, you interpreted BT.709 encoded EXR as PPRGB.

@Mark_G

but none of them seem to allow the map to be depicted on screen in a way that matches how the properly profiled version in Photoshop looks.

Make sure you flag the texture node’s source colorspace correctly, if the texture is Linear PPRGB encoded EXR, flag it as Linear ProPhotoRGB I-D50, don’t tell Blender it’s Linear since Linear option refers to Linear BT.709.

[Mark_G]

Thanks for the confirmation that the Linear space in Blender is BT.709.

In essence, the work flow as I described it works is as if I have re-profiled my ppRGB as BT.709 in Blender. After rendering, I export it from Blender (which still thinks it’s working with BT.709 data), then re-profile it in Photoshop back to ppRGB, which performs this operation in reverse. This is exactly the workflow I have had to use with my old 3D program these many years. In that case, I could never get anyone to admit what colorspace they were using “under the hood.” In Blender’s case, it is a much more capable program and being open source, there isn’t really a hood…

I am happy that both of the color spaces in question are Linear and seem closely related enough that I get predictable and accurate results with this sleight-of-hand. As long as I specify all other material colors, even those fabricated entirely in Blender, with the same color specs expected in ppRGB, I can rely on this method.

As far as your instruction about flagging the texture as ProPhotoRGB I-D50, I tried this using the code you thoughtfully provided. It made the texture look super saturated and not at all like the ppRGB file in Photoshop. I tried using both profiles provided to tag the texture and to export as ppRGB and the results were not at all acceptable. I don’t know if the code somehow differs from the ppRGB profile provided in Photoshop, or if I have used it incorrectly. At any rate, this method requires Blender to convert from ppRGB to BT.709, then convert back to ppRGB on exporting the render.

The sad fact is that BT.709 cannot handle with fidelity the particular colors that are most important to my work. Even in Photoshop, which also has the BT.709 profile available, the tests I’ve run going from 16-bit CMYK to BT.709 RGB and back to CMYK introduces as much cyan into the pure yellows as sRGB does. Because of this, I suspect that 709 uses the sRGB primaries in its definition. If BT.709 could handle my colors, I could sidestep the entire issue and just convert my art directly to BT.709 in Photoshop. It would then be in the native Blender color space and would come back rendered in the same. Unfortunately BT.709 has the same issues that drove me to use ppRGB in the first place.

My only options seem to be:

1. To “deceive” Blender into thinking it is working with BT.709 (when the data is actually ppRGB), and re-profile the supposed BT.709 data back to ppRGB after rendering, upon import into Photoshop. This gives me drab onscreen Blender feedback, but usable, predictable results on export.

2. To find a way to have Blender actually work in ppRGB. This would be marvelous, but I don’t hold out much hope of this being practical given my situation being a fringe case.

or

3. Use method 1, along with some kind of color transform that only affects how Blender provides onscreen feedback, but doesn’t change anything material that affects the render. Some way of telling the main color engine in Blender, “Don’t trouble yourself, you’re dealing with BT.709 color”; while whispering to the module that drives your computer screen, “This project is really ProPhotoRGB.” This would work sort of like fiddling with the tint and color controls on an old TV. It didn’t really change any features of the broadcast; merely how it looked on your TV. Whether such a thing is possible is beyond me.

In any case, if Blender is only able to work in BT.709 color space, then it looks like I will have to continue to deceive it in order to preserve the tints I need.

[Eary_Chow]

@Mark_G

if Blender is only able to work in BT.709 color space

Again, you can change the scene_linear role to the linear version of PPRGB, then Blender has PPRGB working space. To prevent the color picking wheel vales to go crazy, you would also need to set the color_picking role to the power 1.8 version of PPRGB.

@Mark_G

It made the texture look super saturated and not at all like the ppRGB file in Photoshop.

I believe what should happen is that when you convert the texture to PPRGB, the texture should look “super desaturated”, then when you import to Blender and flag it as PPRGB, it should then be “re-saturated back”.

This is what happened at least when I export PPRGB EXR from Darktable and Import it into Blender.

[Mark_G]

It sounds like I am (with your help) within spittin’ distance of my Holy Grail. What I had knocked together was workable. What looks to be possible if I follow your directions correctly would be ideal!

Thank you for your patience with me. While I’ve worked with color for a long time from the printing prepress side, I am a Blender newbie and I don’t think I quite understood which piece goes where. I will look over everything you have written again and try integrating the various profiles into place. It’s quite possible I had the wrong ones in the wrong places.

The only instruction that mystifies me is where I would specify the color picker profile.

Once I get it all in place I’ll report back again.

[Mark_G]

A light bulb just went off, I think…

When you referenced " change the scene_linear role to the linear version of PPRGB" did you mean edit the lines under “roles” in the “config.ocio” file to read:

 # Internal scene linear space
   scene_linear: Linear ProPhoto RGB I-D50
   rendering: Linear ProPhoto RGB I-D50

And “set the color_picking role to the power 1.8 version of PPRGB” change it to read:

  # Distribution of colors in color picker
   color_picking: ProPhoto RGB 1.8 I-D50

I was looking to change settings within Blender…

Also, should either of the following be changed to one of the ProPhoto setups you proveded?

  # Default color space for float images
   default_float: Linear

  # Default color space sequencer is working in
   default_sequencer: sRGB

[Eary_Chow]

@Mark_G

When you referenced " change the scene_linear role to the linear version of PPRGB" did you mean edit the lines under “roles” in the “config.ocio” file to read

Yes

@Mark_G

Also, should either of the following be changed to one of the ProPhoto setups you proveded?

This is the default choice Blender makes when you import EXR (float) or TIFF (byte), if you are going to use PPRGB textures most of the time you can change it so Blender automatically flag the texture as PPRGB for you upon import.

[Mark_G]

This is fantastic!

I have now edited the config file and the maps are importing looking correct. The Blender display is, if anything, a little more saturated than the same map in Photoshop; but then I am dealing with lighting and other 3D vagaries.

The edits did not compromise any of the accurate end results I have been seeing. It just allows me to see my renders within Blender just the way they’ll look later in Photoshop.

Thank you, Eary_Chow, for all your help on this. I know my particular needs not those of the majority of Blender users, but I’m willing to bet there are a lot of professionals who deal with name brand product “photography” who will find this useful. Even if they work in some other flavor of RGB than ppRGB; they can follow your instructions and have a personalized build of Blender that works in their color space.

Blender is a great program, and its greatness is only exceeded by the wonderfully generous volunteers, like you, who bring it to us and keep making it better.