Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Improved XYZ color conversion" and color workflow #36

Closed
GoogleCodeExporter opened this issue Mar 13, 2015 · 34 comments
Closed

"Improved XYZ color conversion" and color workflow #36

GoogleCodeExporter opened this issue Mar 13, 2015 · 34 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1. in the release notes, for 0.16 version you have written :
2. "Improved XYZ color conversion"
3.

What is the expected output? What do you see instead?
I didn't test yet but I just wanted to know what kind of "improvements" you 
made in the XYZ color correction... I made a DCP from TIFF files generated in 
Rec.709 by After Effects CS5 these last days and I've seen a difference between 
the J2C files created by opendcp_j2k and other J2C files made from TIFF files 
in "DCDM XYZ Adobe 5900K gamma 2.6" and converted by opendcp_j2k with the "-x" 
option (to prevent from a double color space correction).

Is that this mismatch I can expect to be corrected with the 0.16 version of 
opendcp ?

What version of the product are you using? On what operating system?
0.16 on Mac OS X

Please provide any additional information below.
I will go in a digital cinema theatre soon... and i will test 5 different 
workflows...

A : After Effects 32-bit linear Universal Printing Density color space -> TIFF 
16-bit Rec.709 RGB -> opendcp_j2k -> J2C XYZ
B : After Effects 32-bit linear Universal Printing Density color space -> TIFF 
16-bit DCDM XYZ -> opendcp_j2k -x -> J2C XYZ
C : After Effects 16-bit no color space -> TIFF 16-bit RGB -> opendcp_j2k -> 
J2C XYZ
D : After Effects 16-bit no color space + color space utilitie "working space 
to DCDM XYZ" -> TIFF 16-bit DCDM XYZ -> opendcp_j2k -x -> J2C XYZ
E : After Effects 32-bit linear Universal Printing Density color space + gamma 
1.22:1 correction -> TIFF 16-bit Rec.709 RGB -> opendcp_j2k -> J2C XYZ

If you have any suggestion tell me... and I will tell wich way is the best to 
maintain correct colors from a calibrated 10-bit HD monitor to a Digital Cinema 
projector...

Thanks (from France ! ^^) for all your amazing work... :)

Original issue reported on code.google.com by fredz...@gmail.com on 29 Jan 2011 at 8:43

@GoogleCodeExporter
Copy link
Author

The color conversion in opendcp is based on a sRGB D65 (2.2 gamma) source to 
the DCI 12-bit profile (2.6 gamma). Color conversion is tricky, because it 
depends on the source/destination and right now there is only the one profile 
in opendcp. It should be better in .16, but it is still not perfect. For now, 
if you can do the conversion in After Effects you'll get the best results. 

Original comment by terrenc...@gmail.com on 29 Jan 2011 at 2:06

@GoogleCodeExporter
Copy link
Author

Hi there!
I noticed a problem in version 0.15 with the lookup-table for linearizing sRGB 
before color transform. I understand that you used ver. 0.15 when you noticed 
the difference with After Effect. So the problem could not be the color 
conversion in that case,  but the linearization before. I think that was a sort 
of "typo". I mean it turns out that the lookup table was generated with 2.6 
instead of 2.2. Having problems myself I plotted the data and there was 100% 
fit with 2.6. So as Rec. 709 uses +/- the same gamma and the same reference 
white as sRGB I think if you correct the lookup table in vers. 0.15 you should 
have the same result as with After Effects or something very near. 
I just downloaded vers. 0.16 and plotted the data of the same lookup-table and 
they are correct now (I mean they are an exponential function 2.2). 
Maybe Terrence generated again the data without realizing that the ones in ver. 
0.15 were not right?
One could do only a tiny little better with a lookup table for linearizing 
incoming sRGB generated with the more complex function still included in the 
sources of 0.15. If a lookup-table must be, why not pick up the exact function?
See attachement.
Best regards
Luca

In the plot magenta is the gamma linearization in the lookup-table of vers. 
0.15, green is 2.2 (like vers. 0.16) and black is like the attached file (the 
more complex function).

Original comment by luca.tri...@gmail.com on 30 Jan 2011 at 2:09

Attachments:

@GoogleCodeExporter
Copy link
Author

Version 0.15 used a LUT based on a 2.6 gamma. The LUT is used for speed 
purposes. In 0.16 the LUT is not used and instead a complex calculation is made 
with an sRGB 2.2 gamma reference and matrix used as the source. In a future 
version a lookup table will be re-implemented with support for different source 
reference whites and gamma. For now sRGB D65 will be assumed, which is probably 
correct most of the time.

Original comment by terrenc...@gmail.com on 30 Jan 2011 at 7:35

@GoogleCodeExporter
Copy link
Author

Thx Terrence and Luca.

There's still a little gamma curve shift between XYZ colors generated by After 
Effects CS5 from sRGB pictures and those generated by opendcp_j2k... I have 
uploaded 2 png images in order to see the differences between them... as you 
can see, the color conversion from After Effects is still the best... less 
banding on low levels... the colors of the original picture are totally 
preserved.

Original comment by fredz...@gmail.com on 4 Feb 2011 at 9:49

Attachments:

@GoogleCodeExporter
Copy link
Author

Mmmh... these pictures have an embedded sRGB profile... it's strange but on 
Firefox or Safari on my Mac they are shown as if they were interpreted with an 
AdobeRGB profile (oversatured colors and too more density)... you can download 
these two png files and then open them in Photoshop, the software will detect 
the sRGB profile and will show you the "true colors" (and "perfect colors" if 
you use color management on a calibrated screen)... I guess it will work... but 
no matter, the gamma curve shift is still visible even if the two pictures are 
bad decoded.

Thank you.

Original comment by fredz...@gmail.com on 4 Feb 2011 at 9:58

@GoogleCodeExporter
Copy link
Author

I think the Adobe conversion uses a D55 reference white. OpenDCP uses D65. 
Which is more correct depends on what the source was. I think a better test 
would be to create solid red, blue, white, green, yellow images that you know 
are D65 sRGB. Then run through the conversion. What you get back out should be 
the same as what you put in. You'll be able to get the exact values rather than 
visually comparing. 

Original comment by terrenc...@gmail.com on 5 Feb 2011 at 12:24

@GoogleCodeExporter
Copy link
Author

After Effects uses D65 for sRGB (can't do anything else, D65 is the reference 
white for sRGB) and uses "D59" to export DCDM in XYZ color space... it should 
use the D55 reference white specified by the DCI (and it was the case before 
the CS5 version) but the problem is that in real life digital projectors are 
not all calibrated on a perfect D55 white ! 3 major reference whites exist 
(including the D55 and the D65 whites)... and the specific "D59" used by After 
Effects to convert images from RGB profiles to the absolut XYZ color space is a 
way to set the white point to an average reference white that is not too far 
from the 3 other mesurable points.

See the pdf file below :
http://movingimagetech.com/papers_pages/White%20Point-digital-ASC.pdf
In the conclusion you can read :
"The current white point specified for film, D55, is impractical and outdated."

Original comment by fredz...@gmail.com on 6 Feb 2011 at 11:30

@GoogleCodeExporter
Copy link
Author

So I made my 5 tests (I used 0.16 version of opendcp for all these tests)... 
remember :
A : After Effects 32-bit linear Universal Printing Density color space -> TIFF 
16-bit Rec.709 RGB -> opendcp_j2k -> J2C XYZ
B : After Effects 32-bit linear Universal Printing Density color space -> TIFF 
16-bit DCDM XYZ -> opendcp_j2k -x -> J2C XYZ
C : After Effects 16-bit no color space -> TIFF 16-bit RGB -> opendcp_j2k -> 
J2C XYZ
D : After Effects 16-bit no color space + color space utilitie "working space 
to DCDM XYZ" -> TIFF 16-bit DCDM XYZ -> opendcp_j2k -x -> J2C XYZ
E : After Effects 32-bit linear Universal Printing Density color space + gamma 
1.22:1 correction -> TIFF 16-bit Rec.709 RGB -> opendcp_j2k -> J2C XYZ

And the best way to reproduce the correct colors on screen is to use the B 
proposition... the better color conversion is made by After Effects with its 
"DCDM X'Y'Z' (Gamma 2.6) 5900K (by Adobe)" color profile applied to a project 
with color management activated. The best way to get great colors with the 
opendcp_j2k color conversion is to use path A... and still needs color 
management into After Effects... but the result is a little lighter and less 
saturated than using exclusively After Effects.

The advantage of After Effects by using the wide space gamut "Universal 
Printing Density Color Space" as a working profile is to keep colors that are 
beyond the "sRGB" or "Rec.709" spaces... and then if they are directly 
converted in XYZ by After Effects itself, we can keep their gorgeous saturation 
(that could be seen on my 10-bit calibrated screen) in the DCP and finally on 
the projector...

But the key of this success is clearly your work on opendcp Terrence... I 
attach files here to this post... you can see the pictures that have served me 
to made the tests and a photo of the Doremi DCP-2000 ingesting the two files I 
made with opendcp... a short and the test ! :)

Thank you very much ! Your tools are amazing... and work very well !!!

For info, the server was a Doremi DCP-2000, the audio was managed by a Dolby 
650D and the projector was a Christie CP2000 ZX. Perfectly functional for 
ingest, video and audio playback !!! :)))



Original comment by fredz...@gmail.com on 12 Feb 2011 at 10:49

Attachments:

@GoogleCodeExporter
Copy link
Author

Hey, wow, thanks for the great information! I'm hoping to continue to improve 
the color conversion, it is turning out to be one of the most complicated 
aspects of this project. My primary focus recently has been the GUI and after 
that I'll start to enhance and improve the other aspects.

Original comment by terrenc...@gmail.com on 12 Feb 2011 at 5:20

@GoogleCodeExporter
Copy link
Author

Hm, It's clear from the beginning that expression B should work best. The 
question is: you care about the color, but did you care also about the gamma? 
Universal printing density have gamma for film (I guess 1.0). In the white 
papers Adobe sugest to work with ProPhotoRGB color profile. I'll test soon your 
B proposition and Adobe proposition. btw I used REC.709 working profile on 
Adobe to DCDM XYZ 5900 and gamma is shifted - black are not perfect black and 
is overall little bit less contrasted.Nothing to do with bits (source is 12 
bit),and range (full range, NOT legal range). Did somebody have same 
observation?

Original comment by rado.mar...@gmail.com on 11 Mar 2011 at 9:52

@GoogleCodeExporter
Copy link
Author

Hi Terrence,

This is an excellent project and well done for all your hard work. I'm just 
starting to test your tools now but I hope to give you detailed feed back as I 
am in active post production work with D-Cinemas in London.

I agree with your point about the complexities of the RGB - XYZ and gamma 
correction, it is a mine filed. But using third party tools which I am lucky to 
have in my company (like Truelight by FilmLight) it is possible to get great 
results in the correct colourspace.

My question is about the KDM encryption. This is the last part of the process 
which I cannot complete using open source tools and the fruits of all your hard 
work. Are you looking into this feature in a next release? I hate to be a pain 
but do you know a timescale before a beta version of this functionality would 
be available? I am very keen to try it out and it would be an excellent 
addition to your fantastic set of DCP tools.

Keep up the great work!

Original comment by tombalkw...@gmail.com on 12 Mar 2011 at 2:24

@GoogleCodeExporter
Copy link
Author

@"rado.markov" :

The "B" color workflow works perfectly and of course I have tested all the 
parameters of the pictures (including tints, saturations, white and black 
levels, knee, gamma... etc.) and even if "Universal Camera Film Printing 
Density" color space is used as linear into After Effects CS5, it doesn't 
change anything for rendering into "DCDM X'Y'Z' (Gamma 2.6) 5900K (by 
Adobe)"... the Adobe software makes the good conversions to produce the true 
XYZ coordinates.

You wrote : "I used REC.709 working profile on Adobe to DCDM XYZ 5900 and gamma 
is shifted - black are not perfect black and is overall little bit less 
contrasted"... how did you see that ? On a digital cinema theater screen ? <Oo> 
???

Adobe white paper doesn't suggest to use "ProPhoto RGB" color profile now (but 
it's still useful in Photoshop and dedicated to replace the old "Adobe RGB 
(1998)")... "ProPhoto RGB" was mentioned for the CS3 version of After 
Effects... since the CS4 version, the "Universal Printing Density Color Space" 
has been created and is really the most accurate space for linear workflows 
using film scans (even recorded in 10-bit log), digital raw files, HD footage 
or raster images... The Rec.709 space is really too small to work with it.. its 
only advantage is to use the same color primaries of your LCD screen (if you 
have a sRGB standard computer screen)... but it is not a "wide gamut" space, it 
can't record huge saturations and vibrant colors that your cinema projector can 
reproduce ! You can use it only if you work exclusively for HDTV (HD television 
and Blu-Ray Discs... and SD and DVDs)...

The "Universal Camera Film Printing Density" profile was developed by Adobe in 
direct response to use testing at The Orphanage (famous VFX company... that has 
sadly closed its doors at the beginning of 2009 !)... but to fully use it, you 
must activate the "32-bits per channel (float)" and "Linearize Working Space" 
options into the After Effects project parameters.

Just one more thing, during the projection of my DCP made by opendcp with the 
"B" workflow, I've felt like if the contrast and the black levels were not 
correct on the theater screen... but it's because i'm used to see my pictures 
on a very good 10-bit calibrated screen with a high-contrast level... and the 
blacks on a screen like mine are really deeper than on a theatre screen... so I 
will make another tests to see if it's not useful to increase the gamma of the 
picture in After Effects before the XYZ conversion to maintain a more accurate 
"perceptual" color workflow. I will make new tests using opendcp between april 
and june I think... and I will post my results here.

At the end, it is possible that the "DCDM X'Y'Z' (Gamma 2.6) 5900K (by Adobe)" 
conversion could correct the native "2.2 gamma" of pictures seen on a HD screen 
to prevent from too contrasted pictures... but if Adobe does that, it's an 
error, because the "2.6 gamma" in a theater is used to see a correct perceptual 
density of pictures... because the audience is in a perfect dark room and eyes 
adjust themselves to their environment ! I think it could be enormous if Adobe 
made such an error... I'll see that...

Original comment by fredz...@gmail.com on 12 Mar 2011 at 3:37

@GoogleCodeExporter
Copy link
Author

Thanks for your feedback!

KDM support is still a few releases out. The first part, encryption is pretty 
much done, just not currently enabled. The KDM portion has not been started. 
Since this is a side project, it is hard to put any timeline on this stuff. 
Some nights I get a couple hours to work on it and other times a week will go 
by without touching it. 

By the way, I have a site http://dcinemaforum.com where these sort of things 
can be discussed in a much better environment. 

Original comment by terrenc...@gmail.com on 12 Mar 2011 at 3:58

@GoogleCodeExporter
Copy link
Author

@fredzarf, wrt theatrical black levels: It's important to remember that 
theatrical screens are never "perfectly dark". There is light spill from 
emergency lights and from the projectors themselves.

You can test this by setting up the theatre in operational mode (dim the 
lights, all required exit lights on etc.) and projecting a black screen package 
-- Use the projector's black test or even take some black frames from 
unencrypted trailer packages if you are unsure about self-made black levels.

What you'll see on the screen is the darkest you'll ever get. It's called 
theatre black and it's not black at all.

Still, like you say, viewers adapt to projected content in this environment and 
one will regularly walk out of a venue and "remember" dead blacks and dark, 
dark nights.

@Tom Balkwill, there actually is an open-source implementation of encrypted 
essence/packages, digital signature and KDM generation. It lives at 
https://github.com/wolfgangw/digital_cinema_tools/wiki/Cinemaslides

Original comment by t...@online.de on 13 Mar 2011 at 7:09

@GoogleCodeExporter
Copy link
Author

@tito

Yes, thanks tito, I know that theatrical screens are never "perfectly dark"... 
and that is the case with all sort of displays (LCD, Plasma... and all kinds of 
projection systems, DLP, SXRD, D-ILA, LCD, CRT... etc)... perhaps things will 
change definitely with the OLED screens in near future.

I compared my own blacks on the DCP to the black directly generated by the 
Doremi server and inserted between videos... it's an evidence, my blacks are ok 
(how can it be different if the values are set to 0 in 32-bit mode ? even with 
a bad conversion, a RGB 0 0 0 pixel is always an XYZ 0 0 0 pixel)... but I just 
said that it was interesting to see how black levels on a theater screen are 
far away from blacks on a 10-bit calibrated LCD screen when you are used to see 
your own pictures on this kind of displays... in front a the theater screen, 
you have the feeling that the blacks are not correct.

My future tests will more concern the gamma... I will determine if I need to 
increase the gamma of one step (2.2 to 2.6) to reproduce the same perceptual 
aspect of the picture to the audience.

Thx ! :)


Original comment by fredz...@gmail.com on 13 Mar 2011 at 9:46

@GoogleCodeExporter
Copy link
Author

Yes, big difference indeed between LCD screens and dlp projection on a 
reflecting screen. I think there are 2 viable ways to go about it:

I think one can get really good at judging the difference by ping-ponging 
material between those 2 environments (LCD and theatre screen) and consciously 
turning the visual experience into a feedback-loop that will help with 
predicting results in the theatrical environment.

Or do it (grading, color decisions, testing) in a theatrical environment in the 
first place. Professionals, who can afford the equipment, do this. They also 
say time and again "It's the only way to do it".

This in addition to correct numbers and math, of course.

Best, Wolfgang Woehl

Original comment by t...@online.de on 13 Mar 2011 at 7:07

@GoogleCodeExporter
Copy link
Author

Original comment by terrenc...@gmail.com on 9 Apr 2011 at 5:54

  • Changed state: Done

@GoogleCodeExporter
Copy link
Author

There are major mistake in the workflow.
A : After Effects 32-bit linear Universal Printing Density color space -> TIFF 
16-bit Rec.709 RGB -> opendcp_j2k -> J2C XYZ
B : After Effects 32-bit linear Universal Printing Density color space -> TIFF 
16-bit DCDM XYZ -> opendcp_j2k -x -> J2C XYZ
C : After Effects 16-bit no color space -> TIFF 16-bit RGB -> opendcp_j2k -> 
J2C XYZ
D : After Effects 16-bit no color space + color space utilitie "working space 
to DCDM XYZ" -> TIFF 16-bit DCDM XYZ -> opendcp_j2k -x -> J2C XYZ
E : After Effects 32-bit linear Universal Printing Density color space + gamma 
1.22:1 correction -> TIFF 16-bit Rec.709 RGB -> opendcp_j2k -> J2C XYZ

If the WORKING space of the project is clear, it's NOT clear what's  are 
properties of the file itself ("Interpret footage as..>main>color space").If 
the fileproperties are set to Rec.709 further using of large color space 
(Universal printing density) does'nt make sense because you are already limited 
on file source color space.
Also other unclear is using output (rendering)color space. If you use DCDM XYZ 
this is monitor profile (color space and not scene color space (see Adobe white 
papers about color space) and as such this is monitor profile and show how 
picture will shown on the given monitor (in this case in digital cinema 
projector)If you render it with this color profile it's can be a problem becaue 
after that you shown on digital cinema which also show wiht 2.6 gamma. This 
mean that once you "raise" gamme in AE when rendering and you raise it one more 
time in the projector/player this mean once raising form 1.8 to 2.6 with 0.6 
and in projector from 1 to 2.6 this mean you give gamma relative to 
originalpicture not 2.6 but nobody know how much exactly. In any case picture 
given on digital cinema screen is little lighter and greyish (gray and low 
contrast).
There should be another way to convert pictures from rec.709to digital cinema 
respecting gamma changes.
Did somebody know something more or have some experience?

Original comment by rado.mar...@gmail.com on 7 May 2011 at 9:32

@GoogleCodeExporter
Copy link
Author

1. In AE CS5, starting with a high res .mov as a source clip, I did this:

-In Color Management tab, Output profile set to "DCDM X'Y'Z' (Gamma 2.6) 5900K 
(by Adobe)". Export as TIFF sequence.

2. Used the JPEG2000 tab in OpenDCP to convert the TIFF sequence to J2K 
sequencee

-DPX Logarithmic checked
-XYZ conversion unchecked
-125 mb/s bandwidth
-8 Threads

The resulting J2K's are pale.  Less contrast, less saturation, and the hue 
slightly changed.  Is anyone else experiencing this????

Original comment by Kenji...@gmail.com on 22 Nov 2011 at 5:54

@GoogleCodeExporter
Copy link
Author

You must uncheck "DPX log" and verify that you render 16-bit TIFF files 
(trillions of colors) and it will work.

Original comment by fredz...@gmail.com on 22 Nov 2011 at 6:43

@GoogleCodeExporter
Copy link
Author

Your images are in the XYZ color space. You can't view them properly on a RGB 
monitor as it doesn't know how to render the colors.

Original comment by terrenc...@gmail.com on 22 Nov 2011 at 3:39

@GoogleCodeExporter
Copy link
Author

In Step 1, I'm using AE to convert to TIFF sequence AND XYZ color space 
simultaneously.  The resulting TIFFs look fine. But when I convert the XYZ 
TIFFs to XYZ J2Ks in opendcp_j2k they have that pale look.  Must be something 
with J2Ks in XYZ color space.

I experienced the same thing using the AE j2k plug-in 
(http://www.fnordware.com/j2k/) to convert the video to XYZ J2Ks all in one 
fell step.

I guess I'll continue this workflow and test it on a digital project to see 
what it looks like. Thanks for everyone's help, you guys rock!

Original comment by Kenji...@gmail.com on 22 Nov 2011 at 6:59

@GoogleCodeExporter
Copy link
Author

Kenji,

you must open the 12-bit XYZ j2c files in Photoshop (verify that you have the 
"JPEG2000.plugin" in "Adobe Photoshop CS5 / Plug-ins / File Formats" folder) 
and assign them the "DCDM X'Y'Z' (Gamma 2.6) 5900K (by Adobe)" color profile... 
and then you'll see your pictures properly ! If it's not the case, it means you 
failed in your color workflow...

Oh I see that the fnordware j2k plug-in has evolved !!! Great news !!! Now you 
can do that directly in After Effects by interpreting your j2c pictures with 
the "DCDM X'Y'Z' (Gamma 2.6) 5900K (by Adobe)" color profile ! Perfect ! It 
works great !!! Thx Kenji, I couldn't see that update of the j2k plug-in 
without your comments here... ;)

Original comment by fredz...@gmail.com on 22 Nov 2011 at 8:22

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

@rado

You wrote your comments long time ago... sorry to answer only today.

I have created more than 50 DCP this last year with openDCP... and the correct 
workflow is still the "B" one tested on Avatar pictures... and my DCP are 
perfect in digital cinemas.

You wrote : "If the WORKING space of the project is clear, it's NOT clear 
what's  are properties of the file itself ("Interpret footage as..>main>color 
space").If the fileproperties are set to Rec.709 further using of large color 
space (Universal printing density) does'nt make sense because you are already 
limited on file source color space."

It makes sense to work in a color space that has a larger gamut than the 
original color space of the files you import in After Effects... like it makes 
sense to work in linear 16 or 32 bits even if your pictures are in 8 or 10 
bits. With a wide gamut display (near the Adobe RGB color space) you can see 
colors that don't exist in the Rec.709 color space... and you can reach these 
colors from the Rec.709 pictures by increasing the saturation during a color 
grade for example or making special effects (what I do in most of my movies)... 
so it's really easy to go further the limits of the Rec.709 color space !

You wrote : "Also other unclear is using output (rendering)color space. If you 
use DCDM XYZ this is monitor profile (color space and not scene color space 
(see Adobe white papers about color space) and as such this is monitor profile 
and show how picture will shown on the given monitor (in this case in digital 
cinema projector)"

No, the DCDM X'Y'Z' (Gamma 2.6) 5900K (by Adobe)" is not a monitor profile made 
to simulate colors in other spaces... it is a color profile that you can use to 
input or output files in After Effects (and now with the new j2k plug-in !)... 
and it works perfectly ! And the gamma is not increased by using this output 
color profile into 16-bit TIFF files and encoding them into 12-bit XYZ j2c 
files... on the cinema screen you have exactly what you have on your wide gamut 
display.

@Kenji

I've tested the j2k plug-in tonight to output 12-bit XYZ j2c files and if the 
color conversion is made without any problem, I see that the bitrate of the 
rendered files is far below the one I configured in the output module of After 
Effects (around 80 Mbps in stead of 238 Mbps !)... mh... strange... I'll see 
that.

Original comment by fredz...@gmail.com on 22 Nov 2011 at 9:33

@GoogleCodeExporter
Copy link
Author

When you load the XYZ TIFF back into Adobe, it basically converts it back into 
RGB for viewing on your monitor. You could do the same thing with the J2C 
files, if you associate the proper profile with the image.

Fnordware is great for you guys working directly in After Effects. It'll save 
you a lot of time.

Original comment by terrenc...@gmail.com on 22 Nov 2011 at 11:38

@GoogleCodeExporter
Copy link
Author

We are trying to use OpenDCP to create a 3D DCP, but the color is always coming 
out extremely wrong. We are using TIFFs as the source files.

I doubt it is because our monitors are RGB and cannot do XYZ, because when we 
use OpenDCP to make independent left and right files and then put them into the 
projector we get a good image.

Does anyone know what might be the problem? Thanks!

Original comment by slotrian...@gmail.com on 17 Aug 2012 at 6:59

@GoogleCodeExporter
Copy link
Author

Comment 15 by fredz...@gmail.com, Mar 13, 2011
"My future tests will more concern the gamma... I will determine if I need to 
increase the gamma of one step (2.2 to 2.6) to reproduce the same perceptual 
aspect of the picture to the audience."

I am wondering about the need of extra gamma adjustments before exporting from 
AE to DCDM. What was the result of your tests? 

Original comment by polonaku...@gmail.com on 31 Dec 2012 at 12:41

@GoogleCodeExporter
Copy link
Author

Original comment by terrenc...@gmail.com on 1 Jan 2013 at 3:15

  • Changed state: Verified

@MCL
Copy link

MCL commented Oct 28, 2015

Hello,

Any further progress on the gamma question ?
I've just done my first DCP:
From Rec709 to DCDM XYZ gamma 2.6 in After Effect exporting directly in .j2C using the J2K pluggin,
then using the MXF and DCP part of OpenDCP.

It's working and the colors are fine, however in the theater the blacks are a bit grey and they let appear some compression artifacts.

Any piece of advice ?

Thank you

@tmeiczin
Copy link
Owner

OpenDCP does not alter the gamma during the MXF and DCP operations, so the issue you are seeing is with AE or the plugin.

@MCL
Copy link

MCL commented Oct 28, 2015

That's what I thought so it has to come from the color conversion in After Effect.
If the conversion from Rec709 to DCDM XYZ is making the image a bit to light in theater. Is there a specific setting I should pay attention to in After Effect ?

I was told I could change the gamma response curve to 2.2 but I don't see where to do that even in the color profile converter effect.

@tmeiczin
Copy link
Owner

Sorry, no idea. I'd suggest trying the Adobe forums.

@MCL
Copy link

MCL commented Oct 29, 2015

No worries.

I think it might come from the fact that the color correction was done on a monitor and not in projection.

A friend told me it gives generally blacks that are +10mV higher than then should be and I should convert it in the first place, to make my SMPTE blacks become Full or CGR blacks.

I'll try to get more infos on that... :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants
@tmeiczin @GoogleCodeExporter @MCL and others