Hi

this is working as intended I would say

The View Transform is applied everywhere else.
That is the issue. I cannot generate the same output as C4D with a script.
If I Batch render the scene via commandline or if I start to render the output files via the Picture Viewer.

So either everything else is broken
or it is just that this script render does not work the same way as all other file outputs in Cinema4D.
And I assume the Batch render and the Picture Viewer render work as customers expect it (otherwise you would have fixed it already).

If you render .exr files, then you have an option to "Bake View Transform".
If you render any other file format, this option is unchangeable and always activated (internally).
And for both output types it does not work to bake the View Transform into the file if I try it via script.

@ferdinand
Thanks for the update.

Ok, as far as I see it, we call the RenderDocument.
This one saves an output image that does not have OCIO applied.
Then we OCIO-transform the bmp that RenderDocument returns.
Then we copy the render settings the user has set for the output image.
And save the bmp to a file with the name name and settings....
not ideal...

Different question:
Which function does Commandline.exe execute to render frames?
Any plans to export this function to the python API?
Then we do not need to use the BMP workaround with RenderDocument()
nor the workaround to save the scene and use the render queue.

@ferdinand

It is a blocking render using Commandline.exe
Are these questions?

An information.
In reply to your statements "The advantage is that with a thread one can realize non-blocking rendering with it" and to use "CallCommand".

But when you start another Cinema 4D.exe, or CommandLine.exe, or c4dpy.exe on the same machine,
they would all have their own render queue.

But if a new instance of C4D does not use the same render queue settings, how does it come that the same render queue is availabIe if I restart C4D?
Thats what I mean. The render queue settings/items are not bound to the executable instance, they are bound to the user settings.
Which means the artist has to clear the render queue every time he starts C4D.
And he looses old items on C4D restart.
But that would be an issue on MacOS only.
And still better than wrong frames.

(not quite sure how you use the CommandLine in this context)
The only Python code which will run in a CommandLine are plugins

Yes, you did not offer to run scripts directly, therefore we have written a plugin.
Our plugin works for 11 years now, since C4D version R16.
(We still have to support older C4D versions as well, but perhaps we create some new connection with a version switch in the future. But for now adding other features is more important)

Renderings in themself are not blocking

I know, I am familiar with the multi-threading of renderers.

Your function doRender() has already implemented blocking.
So blocking is not an issue.

letting GPU render slaves run on a machine an artist is actively working on

I know. We are working with Redshift since the first beta version.
I did not mean that 2 GPUs jobs run at the same time.
(With the exception that we offer the option to split your GPUs if you have multiple installed)
But it can run at night.
And there are CPU renderer which can be assigned to some cores of the machine while an artist is working

Hi @ferdinand

It is a blocking render using Commandline.exe.
And it always output files to disk.

BatchRender would probably change the render queue items if C4D is started by an artist as well.
And the artist might use the render queue for testing/preview.
We can perhaps relink the user prefs folder on Windows, but not for MacOS.

On the other side, CallCommand is a wrapper to emulate a button click in the UI as far as I understand.
And the UI is not available in Commandline.exe.

We have to do some tests.

So, please let's start over here,

Ok, so can we now agree that we are both professional developers and we both both about OCIO.
And get back to the issue that our end customer wants to render frames via a script and not via UI functions.
But still get the same output file.

Hi

We will not go on wild goose hunts for bugs without clear instructions on what is not working and reproduction steps

At first, I just wanted to know if I am missing any flag/option in the script.
Of course I would have send you repro steps if it turns out to be a bug. But it got into a discussion not about how C4D works, more about how OCIO should work.

You actually have to cooperate with us

I am trying. But it is difficult.
You are telling me again and again that I do not know anything about OCIO!

Have you thought that what you stated might be slightly wrong?
e.g. your first statement that started the theory versus reality discussion:

A rendering does not contain the view transform, as this would basically be against everything OCIO is about

As I cannot argue with information. Simple Repro steps to show why I told you you are not 100% right:

• Open C4D, new scene.
• Add some object.
• Set a filename for "Regular Image", but keep all other settings to the default.
• Render to disk in any way.
• The View Transform is baked. And I have NOT enabled any setting. This is the default behavior of C4D. And you cannot disable it.

Cinema 4D is not baking in the view transform everywhere

As you can see in this example.

Back to the main issue "script versus other C4D functionality"
Reproduction steps:
250306_OcioScript.zip

1. Open the scene.

Render with Baked OCIO:
2) Execute "Render to Picture Viewer" (rename the output).
3) Execute "Add to Render Queue", start it (rename the output).
4) Render via commandline (rename the output).

Render without Baked OCIO:
5) Execute the script (rename the output).

Request:
No matter how C4D saves a rendered frame, the file written should always look the same.

refuse to read
which will also explain you what a view is

OK, If you want to hear it from me: The view transform was "invented" to mimic a different display type like a movie screen. This is done not only to have the option to export it for different devices, it is done to have a more physical correct compositing as well (linear space).
But - as I already stated - within your pipeline only (Your OCIO graph columns Texturing, Rendering, Editing).
Not for the final image (column Products).

About your OCIO knowledge:
Let me ask you a question about the OCIO graph you posted: In the third column "Editing" you see the last box states the render in ACEScg. A customer can not display an ACEScg image on his screen. Just try to upload an ACEScg image to Youtube, use it on any website, burn it on a blueray, ...
In your graph: The editing ACEScg box is linked into a "sRGB" and "DCI-P3" color space. How do you think ACEScg is converted into sRGB? You have to bake a transform into the final image.

continue with wild statements ("everything is broken")

That was a simple conclusion....
I never assumed that anyone thinks the right answer is "everything is broken" to the issue.... I simply showed you the alternatives.

Let me explain: You state that it does not make any sense that the view transform is baked into the frame. It is wrong to do that. It should never be applied. So such a behavior is a bug in your eyes. And I took this statement and refer to it as "broken".

BUT: C4D does that by default.
And you cannot disable it (for 8bit output).

And that gets to the conclusion:
A) Either C4D does it wrong since forever (bug/broken).
It should not bake the view transform.
B) C4D does it right.
There is a good reason C4D bakes the view transform.
Customers creates a new scene, renders it and the image saved is the same as he has seen in C4D.
And that leads to the fact that the script render does it wrong.

You did not even mention that you have one of the baking options enabled

I did not enable anything.
C4D default

Hi

Please read the docs I have linked to understand what OCIO is trying to do on a technical level.

I know the different levels of OCIO as I have already implemented OCIO via C++ into an application.
You are right AS LONG AS you are working within your pipeline, the view transform is applied in the display function of every application. E.g. In compositing like Nuke.
But once you render a final image which is not intended to be loaded in any other application afterwards (an image send to the client),
then view transform has to be applied.
And the customer I am working for uses C4D to render final images as well.
This is why they need the view transform baked into the rendered image.

It has nothing to do with exr files

Ok, then I correct: If you render 8bit files, then "Bake View Transform" is enabled by default internally.
And if you render 32bit, then you can choose to enable "Bake View Transform" or not.
Nevertheless it does not work for rendering a frame via script.

Showing RenderDocument sourced images in the Picture Viewer

I am not loading anything into the Picture Viewer.
I stated examples how you can render to a file with C4D.
I was refering to this menu option:

Support Procedures: Reporting Bugs & Crashes

Ok, then I have to report a bug that the "Bake View Transform" does not work with a scripted render.
I assumed there is some kind of undocumented option/flag missing for the script functions.
But as it seems OCIO was not tested for a script render and therefore it is a bug
I send you the customers scene file and rendered images.

Hi

this is working as intended I would say

The View Transform is applied everywhere else.
That is the issue. I cannot generate the same output as C4D with a script.
If I Batch render the scene via commandline or if I start to render the output files via the Picture Viewer.

So either everything else is broken
or it is just that this script render does not work the same way as all other file outputs in Cinema4D.
And I assume the Batch render and the Picture Viewer render work as customers expect it (otherwise you would have fixed it already).

If you render .exr files, then you have an option to "Bake View Transform".
If you render any other file format, this option is unchangeable and always activated (internally).
And for both output types it does not work to bake the View Transform into the file if I try it via script.

Hi

I am using these script lines to render an image:

bmp = c4d.bitmaps.MultipassBitmap(int(arg.width), int(arg.height), c4d.COLORMODE_RGB)
rflags = c4d.RENDERFLAGS_EXTERNAL | c4d.RENDERFLAGS_NODOCUMENTCLONE | c4d.RENDERFLAGS_SHOWERRORS
res = c4d.documents.RenderDocument(doc, rd.GetDataInstance(), bmp, rflags)

But this does not apply the view transform.
Am I missing something?

@Dunhou
I am sorry, but your module uses the exact same code as I have already posted as NOT working (for all cases).
You are reading the information from the document, not the installed plugin.

@ferdinand said in Get information about renderer plugin via Python:

your question is off topic for the forum you have posted in.

Sorry, but this is a C4D SDK question!
It is NOT about the Octane SDK.

"How can I list all installed renderer plugins in C4D with their version?"

Plugins have to provide informations for RegisterVideoPostPlugin().
Like the name and a disklevel (which might or might not set to the same as the plugin version),
I though I can access this information.

There is no (publicly available) standardized interface with which plugins or specifically renderer plugins would store their version.

Ok, I assumed that C4D works just like e.g. the plugin manager in Maya.
Which is able to list the version of each plugin.

And as I have found some script for a probbaly old C4D versions, I assumed there is still a way to do that with the latest version.

plugins = c4d.plugins.GetFirstPlugin()
    while plugins:
        print("Name:", plugins.GetName())
        print("ID:", plugins.GetID())
        if plugins.GetPluginType() == c4d.PLUGINTYPE_SCENESAVER or plugins.GetPluginType() == c4d.PLUGINTYPE_SCENELOADER:
            print("Version:", plugins.GetFileVersion())
        else:
            print("Version:", plugins.GetVersion())
        print("\n")
        plugins = plugins.GetNext()