Bytefox199

On 15.01.2014, at 10:25, TechNova <sunyp..@gmail.com> wrote:

Wolfgang,
I totally agree that it would be very worthwhile to figure out this problem. I know my students would benefit greatly!
Here are some answers to your questions which I hope will help.
1) All the source master files we are working with are ProRes4444 QT movies. They are usually exported from FCP 7 on a Mac running OS X. (they are usually exports from Apple Color or DaVinci Resolve that have been color corrected, and round tripped back to FCP for final Titling and Sound Syncing)
2) I am not sure what you mean by ffprobe? Are you talking about posting a short clip in ProRes4444?
3) Yes. I put the same source material through color transforms in OpenDCP, EasyDCP, and Resolve 10
4) I input the ProRes4444 movie file into Resolve 10 then export 16bit RGB TIFF files with no conversion.
I then (check XYZ conversion) in OpenDCP and go through making a DCP. (let's call it DCP 1)
I then input the ProRes4444 movie into Resolve and select the DCI XYZ 3D LUT, then export as 16 bit RGB TIFF files where I then UNCHECK XYZ conversion in OpenDCP and go through making a DCP (let's call it DCP 2)
I then input the ProRes444 movie into Resolve and use the EasyDCP Creator (in Resolve) to make a DCP (let's call it DCP 3)
I then create a new Resolve session where I import the original source ProRes4444 movie, and DCP 1, 2, 3. Resolve 10 has DCP Player built in, and will apply the XYZ->RGB conversion on playback.
What I notice is that DCP 1 and DCP 2 look very very similar. The Waveform and Vectorscope show some very minute shifts but enough to be considered non consequential. (I'm assuming that this shift has to do where the conversion is happening in the process). When I then compare DCP 1 and DCP 2 to the ProRes4444 source the black level seems elevated almost like a lift in the gamma by maybe 0.2.. When I then compare DCP 3 to the ProRes4444 they are a perfect match. And I found these results to hold true when projecting them in our theater.
So the EasyDCP encode matches the source, but the OpenDCP (whether XYZ converted or not) does not match the source..
Again, all of my students films are mastered to ProRes4444 so I have not been able to check this workflow with any other codec. I wouldn't really want to as we are really happy using ProRes4444 as our mastering codec.
On Tuesday, January 14, 2014 11:23:16 PM UTC-8, Wolfgang Woehl wrote:
Suny,
I understand that it is tempting to workaround these issues (what Eric suggests). But we really should try to get to the bottom of this. I think it's very much worthwhile in the long run.
Are you generating your prores masters on Mac OS X? Can you post a (recent) ffprobe output for an exemplary file?
I'm assuming that in testing you put the exact same source master through the various pipelines -- color transforms in OpenDCP // easyDCP // Resolve 10 respectively?
Resolve 10 X'Y'Z' yields identical results to OpenDCP X'Y'Z', correct?
The only color transform which yields satisfactory results on the big screen is from easyDCP? Can you confirm this for a master which was not generated on Mac OS X // is not Prores?
Thanks in advance for helping to fix this.
Wolfgang
On 14.01.2014, at 21:15, TechNova <sunyp..@gmail.com> wrote:
> Thanks for the reply.
>
> I have tried DCP-o-matic and it produced the exact same results as OpenDCP (I think it borrows it's code for the conversion).
>
> I looked at MPEGStreamClip and could only find Brightnes/Contrast adjustments, and nothing related to minute control of Gamma..
>
> I have Compressor it's just that I find the renders out of compressor to be PAINFULLY slow, even using QMaster..
>
> I will look again at Resolve and see if there are any Gamma specific tools.. didn't see them last I checked..
>
>
>
> On Tuesday, January 14, 2014 11:59:09 AM UTC-8, Eric Sebalsky wrote:
> normally, there should be no gamma shift if properly handled from step 1 on. it's often an interpretation issue and you have to tell the software exactly what it's getting and should do with it. that being said, you can alter gamma with every professional encoder. do you have apple's compressor? there you can alter gamma settings easily by 0.1 steps in either direction (filter tab). in afterFX you would need to introduce a correction layer - but in afterFX you have more control over your matte settings which is the vital part. normally in afterFX a shift should not happen if all project settings are right (all set to 10bit and sRGB and so on). there must be an option in davinci as well for this. i remember going through lots of settings for a project and timeline.
>
> have you tried using DCP-o-matic for the conversion only? it takes the original file and kills the need for an extra TIFF conversions step. find the discussion about that in another thread here! hope it works out for you.
>
> if you have questions about a compressor or mpeg streamclip TIFF workflow, you can also contact me via mail.
> cheers
>
> On Tuesday, January 14, 2014 8:43:01 PM UTC+1, TechNova wrote:
> Hey Eric,
>
> thanks for your reply.
>
> I am using Resolve 10 for these tests. Unfortunately you cannot use any of the integrated EasyDCP settings without paying $1600 to remove the watermark (creator + Player).
>
> I was however able to perform the DCI XYZ transform in Resolve (uncheck in OpenDCP) and that gave me the same results as letting OpenDCP do it. That being said, I think you are definitely on to something about this 0.2 in Gamma difference. That seems right to me. So other than reaching in After Affects, how would I change the Gamma by 0.2? Would that need to be done when making the J2K or do I need to do that on the conversion from ProRes4444 to TIFF files?
>
> thanks!
>
> TN
>
>
> On Monday, January 13, 2014 4:09:35 AM UTC-8, Eric Sebalsky wrote:
> hi! just to give you a very quick response: after reading your message, the issue must be connected to a false gamma range setting during conversion. have you looked into davinci 10? it does have an EasyDCP link integrated and should be able to give exact DCI specs. anyways - try TIFF conversion with afterFX if you have it or even the free MPEG streamclip. in my experience it works just fine. if you have compressor you could also try it with that - there you have the possibility to introduce (like in afterFX) a correction layer that shifts gamma to either 2.4 up or 2.2 down, menaing: play around with 0.2 gamma plus or minus to tackle the problem. and you were right by using sRGB, rec709 is even worse because it has different gamma values. and your problem is definitely a gamma issue. DCPs are gamma 2.4, 12bit - prores standard is gamma 2.2 (if rendered out of final cut for example). maybe this helps, TIPP processing can be tricky when you are not able to change settings or know what is actually happening: http://photo.net/learn/raw/
>
> On Sunday, January 12, 2014 7:40:27 PM UTC+1, TechNova wrote:
> Hi,
>
> I teach at the UCLA Film School and my students are increasingly interested in creating their own DCPs for Film Festival projection and other such venues.
>
> I have been following keenly the development of OpenDCP and have been teaching the underpinnings of creating a DCP in my class.
>
> The school now has a digital projector as well as a Dolby DCP server.
>
> In ALL my attempts to use OpenDCP across ALL iterations I have found that when I import 16bit TIFFs into OpenDCP to create J2K files, that the Black level and Gamma seem to elevate.
>
> Understand that I am not talking about Monitoring XYZ on an RGB monitor which seems to be what the common answer given is, I am looking at the final in our calibrated Movie Theater.
>
> Our workflow generally consists of this pathway:
>
> - Start with ProRes4444 Master QT
> - Input into Da Vinci Resolve to create 16 bit TIFF RGB
> - Input 16 bit RGB TIFFs into OpenDCP (with sRGB selected, Rec709 seems to make it even worse)
> - Sound prepped using AUDACITY
> - DCP made in OpenDCP
>
> We then view the DCP using EasyDCP Player and compare the image to the original ProRes4444 Master, and the black levels seem elevated, and gamma raised.
>
> We then view the DCP in our theater, and notice the EXACT same thing we saw in EasyDCP Player..
>
> So this is not a viewing environment issue, the actual output from OpenDCP does not match the input source file fed into it, when viewed..
>
> What are we doing wrong?
>
> When I did a test using EasyDCP creator, there was no Black Level, or Gamma shift. The DCP in the theater looked exactly like it's ProRes4444 counterpart.
>
> Thanks for the help!
>
> TN
>
> --
> You received this message because you are subscribed to the Google Groups 'opendcp' group.
> To unsubscribe from this group and stop receiving emails from it, send an email to opendcp+u..@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups 'opendcp' group.
To unsubscribe from this group and stop receiving emails from it, send an email to ope..@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.