On Cineplayer with no color conversion it looks right, with reverse XYZ looks like... well, a greenish XYZ reversed images. Also tried the tiff on Davinci. Can't really figure out if Davinci is compensating the preview when I apply the LUT. Not an expert. Maybe try to encode a few frames with dom and color conversion active. Manuel AC On Tue, Jun 13, 2017 at 7:49 PM, Jim Dummett via DCPomatic <dcpomatic(a)carlh.net> wrote: -- http://akadcp.com/ https://www.facebook.com/akadcp

Thanks for your replies Carsten and Manuel. Answers to your Qs below Carsten. On 14/06/2017 11:18, Carsten Kurz wrote: I did this yesterday. On screen, the green cast was less pronounced than on my computer monitor, but I think was still present. Certainly the images had a dull subdued look to them. I also made a DCP in DOM from a Rec709 Quicktime reference file and that looked much more punchy. The director came to the screen test and said the DCP made from the Rec709 was more what he'd aimed for in the grade. So, it looks like my monitoring at office is exaggerating the problems, but that it still persists in the cinema. The TIFF is the incoming TIFF from the post house, which is supposedly XYZ colourspace. Here are the files: XYZ still: https://www.cinebox.co/clockxyz.tiff Rec709 still: https://www.cinebox.co/clockrec709.tiff (from Quicktime for comparison) Once converted to DCP, the centre of the clock appears off-white. I'm a bit at a loss how to trouble-shoot this now. I'd like to determine for sure that I'm not doing anything wrong and DCP-o-matic is doing the colour conversion (or, in this case, the lack of conversion!) correctly before I go back to the post house. Any idea of some other software I could try out making DCP from the XYZ sequence to compare to DCP-o-matic's output? Thanks again for all your help. Jim

Well, the first definitely appears to be in XYZ (or something similar to DCI XYZ). I loaded both images into DCP-o-matic, applied ‚none‘ to the XYZ Tiff, and rec709 to the rec.709 TIFF, then converted both to a DCP. It’s obvious DOM did apply the right conversions (that means ‚no‘ for the XYZ Tiff) to both, as they look pretty similar (e.g. in the red and green borders) in the resulting DCP, but the clock white is indeed off for the XYZ Tiff, but looks ‚white‘ for the rec709 TIFF. The green-shift is pretty strong. I don’t think this goes back to an unbalanced monitoring system. EasyDCP player shows the same greenish tint. Now, am I going to say DOM has the right XYZ handling, and the posthouse did wrong? I don’t know… As I said, with non-standard, or ‚uncommon‘ conversions, there may not be a clear ‚right' or ‚wrong‘, but a ‚how‘. Maybe they were assuming different parameters. What was the original source you gave to the post house, and what (besides the XYZ conversion) did you instruct them to do? At least ask the post house to give you the conversion parameters (color matrix), gamma and whitepoint they used for this job. Now, it seems there are three possible ways to get along: - you can find out how exactly these XYZs were created, and find ways to make a corresponding conversion in DOM. Complicated, but maybe that could work to the accuracy you desire. It depends on what information the post house is willing to to give you on the conversion, and wether these inverse conversion parameters can be applied in DOM (or in another tool). This may sound appealing, but it may be that it is not possible. It could also take a lot more time than it would take the post house to redo the job. - you may tell them they did the conversion wrong, and ask them to redo it. Possibly, with a preview sample at first. - you can scrap the expensive XYZ TIFFs and convert from another source. Wether you like that or not depends on what type of source you have available, or at what stage of the production you handed over this piece to the post house. Do you have a notebook? Can you go to the post house and talk to them? You can load both DCPs and the TIFFs into Doremi Cineplayer evaluation and apply different inverse color conversions (typically, from XYZ back to sRGB). When I load the XYZ TIFF into Cineplayer and apply the inverse XYZ->RGB (for the monitor display), I get the same greenish tint on the clock, but strong red and green on the borders. If you show this to them, they may be convinced to look back at what they did, because the XYZ TIFF’s clock looks greenish with Doremis inverse XYZ->sRGB display. You can actually load both the XYZ TIFF and the DCP created by DOM into the player and demonstrate that both show the same green tinted clock. The more tests I am doing with this TIFF, the more I am convinced they did not apply the proper parameters to the conversion you need for DOM. It has to be CIE XYZ with a gamma of 2.6 As another reference, you may try OpenDCP. BUT - one important thing, neither DOM nor OpenDCP do apply color conversion if you use preexisting XZY files and tell them to use ‚no conversion‘. I guess you understand the difference between applying a color conversion with wrong/slightly ‚off‘ parameters, and doing NO color conversion at all. If you use XYZ TIFFs in DOM and select ‚none‘ for color conversion - all DCP-o-matic does is the J2C encoding (Carl may correct me on this). So, as long as both apps follow that route, there is no difference between DOMs ‚none‘ and OpenDCPs ‚none‘. So - it will be the same in OpenDCP. As a matter of fact, I just did a test with your XYZ TIFF in OpenDCP, disabling XYZ conversion - and it gave the same result as DCP-o-matic. I could try other software as well, but I don’t think it will change something. - Carsten

Not to pile on, but rather to put these graphics into the mix should this thread help anyone in the future… Here are two shots from the site 24p<http://24p.com/wordpress/?p=340> that show an RGB file that is converted to XYZ. It doesn’t take into account other changes like 2.6 gamma and white point differences. RGB XYZ

Well, the first definitely appears to be in XYZ (or something similar to DCI XYZ). I loaded both images into DCP-o-matic, applied ‚none‘ to the XYZ Tiff, and rec709 to the rec.709 TIFF, then converted both to a DCP. It’s obvious DOM did apply the right conversions (that means ‚no‘ for the XYZ Tiff) to both, as they look pretty similar (e.g. in the red and green borders) in the resulting DCP, but the clock white is indeed off for the XYZ Tiff, but looks ‚white‘ for the rec709 TIFF. The green-shift is pretty strong. I don’t think this goes back to an unbalanced monitoring system. EasyDCP player shows the same greenish tint. Now, am I going to say DOM has the right XYZ handling, and the posthouse did wrong? I don’t know… As I said, with non-standard, or ‚uncommon‘ conversions, there may not be a clear ‚right' or ‚wrong‘, but a ‚how‘. Maybe they were assuming different parameters. What was the original source you gave to the post house, and what (besides the XYZ conversion) did you instruct them to do? At least ask the post house to give you the conversion parameters (color matrix), gamma and whitepoint they used for this job. Now, it seems there are three possible ways to get along: - you can find out how exactly these XYZs were created, and find ways to make a corresponding conversion in DOM. Complicated, but maybe that could work to the accuracy you desire. It depends on what information the post house is willing to to give you on the conversion, and wether these inverse conversion parameters can be applied in DOM (or in another tool). This may sound appealing, but it may be that it is not possible. It could also take a lot more time than it would take the post house to redo the job. - you may tell them they did the conversion wrong, and ask them to redo it. Possibly, with a preview sample at first. - you can scrap the expensive XYZ TIFFs and convert from another source. Wether you like that or not depends on what type of source you have available, or at what stage of the production you handed over this piece to the post house. Do you have a notebook? Can you go to the post house and talk to them? You can load both DCPs and the TIFFs into Doremi Cineplayer evaluation and apply different inverse color conversions (typically, from XYZ back to sRGB). When I load the XYZ TIFF into Cineplayer and apply the inverse XYZ->RGB (for the monitor display), I get the same greenish tint on the clock, but strong red and green on the borders. If you show this to them, they may be convinced to look back at what they did, because the XYZ TIFF’s clock looks greenish with Doremis inverse XYZ->sRGB display. You can actually load both the XYZ TIFF and the DCP created by DOM into the player and demonstrate that both show the same green tinted clock. The more tests I am doing with this TIFF, the more I am convinced they did not apply the proper parameters to the conversion you need for DOM. It has to be CIE XYZ with a gamma of 2.6 As another reference, you may try OpenDCP. BUT - one important thing, neither DOM nor OpenDCP do apply color conversion if you use preexisting XZY files and tell them to use ‚no conversion‘. I guess you understand the difference between applying a color conversion with wrong/slightly ‚off‘ parameters, and doing NO color conversion at all. If you use XYZ TIFFs in DOM and select ‚none‘ for color conversion - all DCP-o-matic does is the J2C encoding (Carl may correct me on this). So, as long as both apps follow that route, there is no difference between DOMs ‚none‘ and OpenDCPs ‚none‘. So - it will be the same in OpenDCP. As a matter of fact, I just did a test with your XYZ TIFF in OpenDCP, disabling XYZ conversion - and it gave the same result as DCP-o-matic. Look at the attached image - this is from your XYZ-Tiff fed through OpenDCP and reconverted to sRGB. I could try other software as well, but I don’t think it will change something. - Carsten

Hi Carl + Carsten. Really sorry I've not come back on this yet. Have got sidetracked by another project which is consuming all my time. But thanks loads Carsten for all the detailed info. I intend to get back on the case next week and will post on the list when I have got to the bottom of it. My working assumption at present is that the post house exported the TIFF image sequence with wrong white point. Jim On 03/07/2017 16:19, Carl Hetherington wrote:

Hi Carsten. Hmm that's interesting about Resolve. The post house presented the image sequence as being a "DCDM" which I took to mean it should already be in DCI colour space. NB The post house weren't contracted by me - the filmmakers got these materials made up and I was just presented with them to make the DCP. Thanks again for all your help with this. Jim On 04/07/2017 12:19, Carsten Kurz wrote:

Also - I think this is important to stress - we always communicate XYZ, Gamma 2.6 for DCI - however, these are the projection parameters. The DCI projector uses a display-gamma of 2.6. This clearly means - we must not apply a Gamma of 2.6 towards our source footage, but actually an INVERSE 2.6 gamma, so that the DCI projector displays it correctly using it’s calibrated gamma of 2.6. DCP-o-matic has this explicitly right, quoting in it’s color conversion dialog: ‚inverse 2.6 gamma correction on output‘ as the final stage. That also means, DCI corrected TIFFs or J2Ks will usually appear flatter (‚softer‘) compared against their source footage when viewed without correction. Which is the case when you look at DCPs uncorrected. - Carsten