Closed GoogleCodeExporter closed 9 years ago
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
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:
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
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:
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
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
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
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:
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
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
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
@"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
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
@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
@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
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
Original comment by terrenc...@gmail.com
on 9 Apr 2011 at 5:54
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
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
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
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
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
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
[deleted comment]
@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
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
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
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
Original comment by terrenc...@gmail.com
on 1 Jan 2013 at 3:15
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
OpenDCP does not alter the gamma during the MXF and DCP operations, so the issue you are seeing is with AE or the plugin.
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.
Sorry, no idea. I'd suggest trying the Adobe forums.
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... :)
Original issue reported on code.google.com by
fredz...@gmail.com
on 29 Jan 2011 at 8:43