We are still having problems with the tile render and gamma correction.
After you added the gamma correction on the 3ds command script we stop to have problems with gamma when we send normal renders. The problem is the tile render!
We use gamma correction with 2.2 on the input and output
What seems to happen is that, the tiles are render correctly (I see the strips and they are OK), but when the assembler is done the gamma is repeated and the final image is wrong! And this problem is common to both scripts!
We have to have a way to turn off the gamma correction on the assembler, please!
After done several experiences we come to the conclusion that the only way to respect the gamma correction on a tile render is to use the 3ds command with the gamma turn on and with 1.0 on the input and 1.001 on the output. Very strange!
I ask you to also insert on the 3dsmax script the gamma option as you inserted on the 3ds command.
Another thing is to control if dealine deletes the strips or not. At this moment if you send a tile render in 3dsmax the tiles are not deleted, but if you send by 3ds command the strips are deleted. I what a option (in both scripts) to control if the strips are deleted or not after the final assembler.
I saw on another post on the forum the discussion of sending the assembler as a dependent job, I vote for this option!
The ideal would be to have the option to group all the tiles in one job and have a second job dependent to that group that would do the assembler (similar to what backburner does), because sometimes we have to send several high resolution images to render and if I send 20 images in 20 strips it gives me 400 jobs on the monitor!!! And it is very confusing to control so many jobs on the monitor that way.
Thanks for this info. For 3ds Command, we’ll now ignore the gamma submission option when stitching the final image. This will fix this problem. When you say the problem is common to both scripts, are you referring to the 3ds Command and 3dsmax plugins for Deadline? Note that the strip rendering of 3ds Command and the tile rendering of 3dsmax are completely different features. The strip rendering uses the built in strip rendering that 3dsmaxcmd.exe offers, while tile rendering uses our own assembly application to build the final image, which as far as we know, respects the brightness of the original tiles.
We haven’t found a simple override for the gamma correction that we can use with our 3dsmax plugin. In all of our tests we’ve done here with the 3dsmax plugin, we’ve found that Deadline has always respected the gamma setting and the images are rendered properly. Until we can reproduce this problem like we could with the 3ds Command plugin, we likely won’t look to add an option like this. If you can send us a very simple test scene that reproduces the gamma problems using the 3dsmax plugin, we will try it out here. We would love to get this one figured out, but until we can reproduce it here, there isn’t much we can do.
As I mentioned above, the strip rendering of 3ds Command and the tile rendering of 3dsmax are completely different features. The strip stitching option in 3dsmaxcmd.exe automatically deletes the strip images, and there isn’t an option to tell it to do otherwise. The option for deleting the tile images for the 3dsmax tile render is already on our todo list, but we don’t have an timeline on when we will be implementing this (our current focus is on the OS X version).
The reason we implemented the separate job approach was that this would allow you to tile render sequences of images, in addition to single frames. However, we’re finding that no one really uses tile rendering to render sequences, so for the sake of reducing confusion, it might make sense to use just a single job where each task represents a tile. Then a full tile rendering and assembly setup would only need two jobs. This is also on our todo list, but again, we likely won’t visit this until we’re further along with the OS X version.
Attached is a 3ds Command patch that doesn’t apply the gamma settings when stitching the final image. You can install it by unzipping it to \your\repository\plugins\3dsCmd.
Thanks for your quick answer.
The new patch for the 3ds command resolved the gamma problem of the tile render!
As for the 3dsmax plugin…
I know that the two scripts are totally different and use different ways to render a image.
“When you say the problem is common to both scripts, are you referring to the 3ds Command and 3dsmax plugins for Deadline? “
Yes! As I sad the problem is solved on the 3ds command ( with the new patch) but is also happening using the 3dsmax plugin for deadline. I send you a max file that I already posted on another time that uses gamma correction. If you respect the gamma options on this file (the options are the same as in the print screen preferences) and send a image in tile render with the 3dsmax deadline plugin, the final image will be different from the one rendered without the tile render. If you can’t reproduce it let me know.
Ah, now I understand. I tested this scene out with a tile job and sure enough, the gamma settings weren’t being respected. That explains why I could never reproduce this gamma problem before - I was always testing normal rendering and not tile rendering. At first I thought you meant that the tile assembler application wasn’t respecting the gamma setting, but really it was the individual tiles that weren’t being saved out with the gamma correction. We seemed to have fixed this, and we’ve posted a patch which you can unzip to \your\repository\plugins\3dsmax. You should probably backup all the *.dlx files in this folder first, just in case.
