Hello:
Is it possible to store the displaygroup/displaycolor in a session file? I've got a python script that uses this command:
setIntProperty("#RVDisplayColor.color.sRGB", [0])
And I was wondering if it's possible to store that in a session file, something like:
displayGroup0_colorPipeline_0 : RVDisplayColor
{
color
{
int sRGB = 0
}
}
Thanks!
jake
Hi Jake,
Can you please explain what the goal is here a little more?
Along with the new pipeline groups (like you are talking about here for the display) we have also introduced Display Profiles. They allow you to set specific preferred default settings on a specific display to get away from dragging these kinds of settings along with sessions. We found from feedback from our users that it was dangerous to store display state in the session since sessions are shared all the time and the displays won't necessarily match each time the session is loaded and viewed.
Here is the relevant documentation about Display Profiles:
Please have a look and then let me know more about your goal and how you want to proceed.
Thanks,
Jon
Sure thing! I'm writing a python script that will generate a session file to always be run on a specific machine so I always know what the display's colorspace is going to be (View->Linear to Display Correction = No conversion). The problem is that in my session file I'm pulling in DPX's and Tiffs that seem to cause RV to default my display to sRGB (perhaps sourcesetup.py is setting this?) but I actually need it to be set to No Conversion. For the source images I can put a :
sourceGroup000013_tolinPipeline_0 : RVLinearize (1)
{
color
{
int logtype = 0
}
}
To force the source back to linear but I can't seem to do that with the display. So, I'm always having to click on my displays and set them to No Conversion. I was hoping to just embed that into the .rv file so whoever is driving our rounds doesn't have to click on the No Conversion menu item each time. I could probably just write a python script to force the displays to No Conversion but was hoping to have it in the .rv file since every display here is the same colorspace so I don't have to make everyone load my plugin . Does that make sense? Let me know if I need to clarify anything. Thanks!
Jake
Hi Jake,
I am going to take a step back first to explain how RV tackles these color issues so that together we can find a path to a solution for your needs.
To start off I want to explain the way RV loads and presents all material you load. The first thing RV does is look for a way to linearize the colorspace of the the incoming source from either its metadata or through some heuristics of our own. This is what you see set under the Color menu when you load a source in RV. (All of this by the way is controlled in a Python package called source_setup that you can take a look at yourself. Occasionally a studio will choose to make their own custom source setup when they need to diverge from the default behavior of RV, but there are many ways to control these settings.)
Next RV will make an educated guess about the output display transform from linear color space (with rec709 primaries). The default value for the display transform is sRGB and you see this set under the View menu (as you have reported). The display transform is associated with the display devices and not with the media. This means two things.
First, there can be many display transforms used during in a given RV session. One for a projector, an SDI display, or perhaps multiple monitors and so on. The upper tool bar pull down shows the options for the specific display you are looking at and varies from screen to screen (display to display).
Second the display transform is neither saved in the session nor restored from the session file, because it has nothing to do with the media or session.
It is our intention to provide centralized control for custom view/display settings through the Display Profiles I alluded to before. If you find that you prefer something different that RV's default behavior then I think you will find it best to use those. Once you dial in the settings you like on one of the common displays used throughout your studio, then you can save that profile somewhere on your RV_SUPPORT_PATH and share them with all your users (assuming the location on the support path is network accessible).
Please give them a shot and let me know if that will work. The next best option would be to make a package that always forces the view correction off.
Thanks,
Jon
Jon:
Thanks for the explanation of how RV works! I'll give the display profiles some testing and like you said, if that doesn't work, I'll write a python script to force off the view corrections. I guess we're a bit different than other places and most of our files are stored linearly or the header data is incorrect. Thanks again.
Jake
Great Jake! Please keep us posted!
Thanks,
Jon
Hi Jon,
I'm not a pipeline guy (so please bear with me), but I am experiencing a similar problem where we are using rvio to generate libx264 quicktimes (using rvio version 4.2.0). For some reason (probably in the metadata) I am taking an sRGB source file and generating the quicktime but, regardless of the various rvio options that I use, RV wants to recognize the QT's colorspace as being rec709. Changing the color back to sRGB in the color menu gets the color to be accurate (but this is obviously a nuisance every time we are loading an internal .mov file.
I have tried using the -insrgb -outsrgb on the command line. Likewise I have played with the -outparams colorspace, color_primaries, and color_trc parameters (e.g. -outparams vcc:colorspace=0 vcc:color_primaries=7, etc.) and, regardless of the integers that I put in there, it doesn't appear to have any effect on these values in the metadata of the movie file itself (which, using RV's 'view info' shows them to be Rec709). On a larger point, the documentation for xlib264 is maddening - is there anyway to get something more than a passing reference in the user manual and dumping all the options using the rvio -versions command? For a layman like myself at a small studio it can be a real time drag and the online forums are all over the place because you used to use x264 and not libx264.
Anyway, I understand the point about not wanting to override RV's source_setup file to manually force RV to load color as sRGB (we have an Alexa show in-house as well, so that is just causing problems elsewhere), but can you point me to whatever mistake you think I might be making in the transcoding process (again from sRGB targas to sRGB libx264 quicktimes) which might be causing the header information to be recorded in such a way that RV thinks the Color should be rec709.
Here is the basic command line that we are using at the moment:
<!--StartFragment-->/Applications/RV-4.2.0/RV64.app/Contents/MacOS/rvio_hw -insrgb\
/shows.local/mmed_206/sequences/cv/cv206_03/images/comps/cv206_03_comp_v005/cv206_03_comp_v005.1000-1065####.tga -codec libx264 \
-outparams vcc:colorspace=0 vcc:color_primaries=7 vcc:color_trc=13 vcc:b=12500000 -outres 1920 1080 -outsrgb -o \
/shows.local/mmed_206/sequences/cv/cv206_03/images/comps/cv206_03_comp_v005/cv206_03_comp_v005.mov -vv
Thanks!
Michael
Hi Michael,
First of all I feel you on the x264 thing. Just so you know we pass along all of the arguments directly to the underlying libx264 codec. The arguments have a 1-to-1 mapping between -outparams and the full x264 options. If you are having trouble making the translation between their native commands and the RVIO accepted ones please let me know I can help you make the translation.
As far as the color encoding goes would you be willing to open a private ticket and share a sample file with us? I want to make sure we seeing the same behavior before I start making suggestions.
Thanks,
Jon
Thanks for the quick response Jon. I'll set up a private ticket now. Also, if there was a page in your documentation that showed how the native x264 codec commands link up with the libx264 commands (and what they do) I think that would be helpful. Our IO person has been using the previous version of rvio to generate some client quicktimes for another show because he hasn't been able how to translate many of the encoding features that he's learned previously to the new libx264 version.
HI Jon, I just submitted the following private request:
which has a single frame for you to take a look at transcoding to see if you can repeat the issue.
Thanks again for your help.
-Michael
(For posterity passing "-outparams vcc:color_trc=2" will create a movie that will load back as sRGB)