color correction

[GoogleCodeExporter]

What program can do color correction on linux?
I understand that this does not apply to opencinematools, but i need to find a 
program for this task.

Original issue reported on code.google.com by melnikov...@gmail.com on 15 Jul 2009 at 8:56

[GoogleCodeExporter]

ImageMagick is fairly good simple things.  The -recolor and -fx operations can 
handle
things like a RGB to XYZ conversion.

Original comment by shade...@gmail.com on 23 Aug 2009 at 5:07

[GoogleCodeExporter]

Related to this topic i would just inform WIN user that is possible export form 
Adobe AE Cs3 and above with DCDM color preset (XYZ D50 2.6 gamma) using 
integrated 
new color workflow management module.

For AE 7 users you can download XYZ ICC profile (D50) from ICC web site and 
apply 
using convert color profile. ATTENTION gamma adjust needed anyway.

Any other suggestion would be appreciated.

cheers
Tim

Original comment by timothy_...@hotmail.com on 25 Sep 2009 at 12:08

[GoogleCodeExporter]

Hi Tim,

Glad to know that AE CS3 has this output option and this work great,the only 
problem 
is when I feed the tiff sequence to opencinematools, libtiff continue to show 
two 
pop ups for EVERY frame it converted and I need to press enter 2 times for 
every 
frame.This does not affect the conversion but just disturbing and make me 
unable to 
convert a 60 mins clip.24x60x60x2 makes me need to press enter about 200,000 
times. 
The pop up is something like:

untitled_001.tif unknown field with tag 34377 (0x8649) ignored

untitled_001.tif unknown field with tag 34675 (0x8773) ignored

someone said the pop up is related to the internal tag of adobe

any solutions?

Original comment by muiyings...@live.cn on 30 Dec 2009 at 10:22

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I suggest you to use ImageMagick before to use OCT. To make "standart" tiff 
files.

For those who are on AfterEffect, could you please convert this test pattern 
(attached file) and post the result 
here ?

Original comment by vincent....@gmail.com on 31 Dec 2009 at 12:50

Attachments:

• Test_conversion_v1_RVB16D65.zip

[GoogleCodeExporter]

It's because I'm on MacOSX, wothout AffterEffect. And I'm try to find an 
another solution too make good 
color/whitepoint/gamma conversion.

and... do you have news from the developer of OpenCinemaTools ? :-(

Original comment by vincent....@gmail.com on 31 Dec 2009 at 12:52

[GoogleCodeExporter]

Wrt Tiff tags: The problem is /not/ Adobe AE, the TIFF specs allow for 
arbitrary sets
of tags (You can search for vendor-specific tags at
http://www.awaresystems.be/imaging/tiff/tifftags/search.html?q=0x8769&Submit=Fin
d+Tags).
Obviously DCP Maker needs to be fixed here so that unknown (and unneeded) tags 
are
effectively ignored.

Wolfgang Woehl

Original comment by photonra...@gmail.com on 31 Dec 2009 at 1:47

[GoogleCodeExporter]

the DCDM output of AE is something look like the attached file.

You can test in apple color sync or in threater to see the result

Original comment by muiyings...@live.cn on 2 Jan 2010 at 12:51

Attachments:

• dcdm-xyz-gamma26-5900k-adobe.zip

[GoogleCodeExporter]

combine with ae dcdm output,the remaining blocking stones of opencinematools 
are:

1.encryption feature

2.ignore unknown tag

3.convesion time.(I am on a little bit old computer and the conversion time is 
about 
10s PER FRAME).That means the conversion time is 240 X length of your clip.I 
wonder 
how much help a fast computer is.

Original comment by muiyings...@live.cn on 2 Jan 2010 at 1:03

[GoogleCodeExporter]

I appreciate the concept of opencinematool because it is basically a simple 
format 
conversion and some "cheap" production house "caring" for independent filmmaker 
will 
charge you several thousands dollars or euro for a 90 mins film and you will 
find 
that yourself can convert a better result than them if you have the tools. 

Original comment by muiyings...@live.cn on 2 Jan 2010 at 1:13

[GoogleCodeExporter]

muiyingstorage, 

wrt JPEG2000 encoding: Yes, fast chips help. Much potential for CUDA-based
implementations (see http://cuj2k.sourceforge.net/index.html for one example).

Wrt your file (dcdm-xyz-gamma26-5900k-adobe.zip): To me the colors don't look 
right.
What am I missing?

just a tiny little nit-pick here because this is so easily (and often) 
overlooked, if
you allow:

opencinematools is 3 tiny tools to write xml plus a rudimentary gui. That's it. 
Like
the author mentions, btw, it relies heavily on asdcplib etc.
   It's not exactly lovingly maintained, too. Actually it's output is not even usable
on all servers so you have to write parts of the CPL's, PKL's and ASSETMAP's by 
hand
or with your own scripts.
   So there, and sorry if this is all too obvious, which I'm sure it is to anyone
with an adjusted and reality-based set of expectations.

Wolfgang Woehl

Original comment by photonra...@gmail.com on 2 Jan 2010 at 2:43

[GoogleCodeExporter]

the attachment is converted by easydcp (sorry,the screen capture program can 
only 
saved in jpg format)

If you decrease the brightness of the one converted by after effect,they(ae and 
easydcp) will match better.

the algorithm of easydcp may be a little better

Original comment by muiyings...@live.cn on 3 Jan 2010 at 4:44

Attachments:

• easydcp.jpg

[GoogleCodeExporter]

 you still need to manually rewrite the files to play on every server for some 
commercial software.(e.g. wraptor)

commercial software has many constrains too and usually intentionally hide some 
features and charge you this and that to get the full functions.

but the conversion time of easydcp is quite fast,about 6x realtime.

overall,ae,imagemagick and opencinematools can help you if the clip is not too 
long 

Original comment by muiyings...@live.cn on 3 Jan 2010 at 5:09

[GoogleCodeExporter]

Hi muiyingstorage,

not to be misunderstood: I'm all for an open source workflow -- To me it offers 
a
number of advantages. I simply think it's important to keep in mind that
"Opencinematools" is glue software, a frontend to a number of external tools. 
Which
means you can tweak and adjust these tools whenever something better/faster 
comes up.
Good and classic modular *nix approach.
   But I don't expect major missing features to come up here (like encryption
support). "Opencinematools" seems a bit like a proof-of-concept project and be 
done
with it -- abandoned, in other words. I'd be glad to be proved wrong, though.

Wrt your first file: I was looking at it with geeqie which screwed me bad.
ImageMagick's display is, of course, more reliable and it shows that the gamma 
is off
a tad.

Btw: How did you come up with 5900K?
Be good, Wolfgang Woehl

Original comment by photonra...@gmail.com on 3 Jan 2010 at 8:57

[GoogleCodeExporter]

it is the output option of color management in cs4,only one choice of "DCDM 
X'Y'Z' 
(gamma 2.6) 5900K (by Adobe)" details here:

http://www.adobe.com/devnet/aftereffects/articles/color_management_workflow/ae_c
olor_
mgmt_wkflow.pdf

I found that there is a free plugin to convert j2k in after effect,it may help 
in 
conversion speed.I have not tried

Original comment by muiyings...@live.cn on 3 Jan 2010 at 3:15

[GoogleCodeExporter]

Interesting, thanks

Original comment by photonra...@gmail.com on 3 Jan 2010 at 3:23

[GoogleCodeExporter]

Wrt white point:

Just found http://www.movingimagetech.com/White%20Point-digital-ASC.pdf (by 
David
Richards, 2003) In it he concludes with some practical white point numbers that
actually ended up in the DCI specs:

x 0.314 ± .006 and y 0.351 ± .006 which sits at a right angle to the line you 
can
draw between D50 and D65 (the line is called daylight locus if I got that 
right).

So, it's not D50, not D59 either and I guess we'll have to get out the math 
books to
get the right adaption matrix :) I'll post whatever I come up with.

Wolfgang Woehl

Original comment by photonra...@gmail.com on 3 Jan 2010 at 6:20

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi All.

Greetings from Milan, hope everything is well with you.
Glad to see the board so active since our first post.

@ muiyings sorry for the delay; regarding your question about popups; sincerely 
we 
weren't able to replicate this problem, we're on XPx64, we use only command 
line 
tools.
Everything worked properly from J2K encoding to wrapping, all the packges were 
ingested and played back without problem on all over the server.
The only known problem is the inability to wrap 3d mxf stream with 
opencinematools.

Now, my point of view about color conversion; sincerely the best method is 
implement 
ctl in a Pipeline but since this process involve good Knowdlege of C++ cooding 
i 
think is not suitable to the most of users.

The simplest method is to do color transform with java app such imajeJ or 
choose 
free alternative like imageMagick  (portable is better) or still do it directly 
inside AE with integrated color profile tools (up to cs2) color-managment 
module 
(cs3-cs4).

About workflow; assuming AE is intended as internal linear color managment tool 
all 
you have to do is simply apply a color profile transform plug using ICC RGB-XYZ 
D50 
(wich is freely downloadble on ICC site) and THEN apply a gamma 2.6 as 
specified 
from within DCI spec.

Now export in 16 bit TIFF NO COMPRESSION and covert them with last build of J2K 
encoding tool from OpenJpeg2000 project (using cinema 2k/4k option), inspect 
j2k 
frames with j2k viewer and than wrap them with DCP tools.
All the basic tests we've done give us a good (screen) feedback; assuming this 
process is ideal only for test purpose or home/indie project; you can obtain 
good 
results as well.

About the project author, he started with a good idea and made a good work (at 
this 
point); the idea bhind open dcp tools is intended to stay in the open-project 
domain, source are freely inspectable and everyone of us can improve the code; 
we 
just started looking at the sources to see if we can manage to improve or build 
future releases but would be great if everyone of you with good programming 
skills 
will do it the same.

Cheers

Original comment by timothy_...@hotmail.com on 4 Jan 2010 at 12:48

[GoogleCodeExporter]

Vincent, muyingstorage, Timothy, Rado, 
   something interesting came up which sort of complicates (but also clarifies)
things wrt mastering white/calibration white etc.

A paper in SMPTE Journal 10/2009 reports the results of the "SMPTE Digital 
Cinema
White Gamut Practices Study Group". They looked at practices ranging from 
production
through to exhibition and conclude:

"Regarding a specific white point for digital cinema, there is wide-spread
disagreement across the production, exhibition and manufacturing communities.
Practices in mastering already diverge from practices in exhibition. For as 
long as
this situation goes unsettled, the promise of digital cinema to deliver to 
audiences
technically-accurate renditions of a creative vision will go unrealized."

In the study they reviewed DCPs from current digital cinema releases, recorded 
and
analyzed projector alignments in the field and assessed the impact on current 
DC-28
work and documentation. Lots of interesting data in the article.

Another quote: "[...] if your DI mastering suite were set up in RGB for a D55 
white
point at 48 cd/m², projectors in current digital cinema exhibition practice, 
using
the projector configuration file DCDM_XYZ_239, would not accurately reproduce 
the
encoded master at peak white."

They propose "a defined White Gamut for digital cinema to provide for 
consistent and
repeatable results from mastering through to the units in the field."

So, Rado, it's not all that straightforward. And why not share some knowledge 
along
the way? Have you read the report? What are your conclusions?

Wolfgang Woehl

Original comment by photonra...@gmail.com on 13 Jan 2010 at 6:13

[GoogleCodeExporter]

Hello everyone - first post here! Currently writing a Mac OSX GUI that should 
bring
the user from start to finish using the openjpeg2000 library and opencinematools
libraries. Implementing CTL is an interesting concept but would definitely 
require a
lot of code and overhaul.

I do have access to a Autodesk LUT that is linear RGB to DCDM XYZ if anyone is
interested - I work a lot in Autodesk Lustre so I can output to gamma 2.6 DCDM 
in
faster than realtime but I still need to encode JPEG2000s....

I am interested in performance - compared to easyDCP the encoding of j2ks in
openjpeg2000 is significantly slower - any thoughts on this?

Thanks to everyone involved,
Greg

Original comment by gregcot...@gmail.com on 29 Jan 2010 at 4:59

[GoogleCodeExporter]

Hi,

You're working on MacOSX GUI ?! Good news ! How can I help you ? Could I be a 
beta tester ? 
vincent.zorzi@libertysurf.fr

:)

Original comment by vincent....@gmail.com on 29 Jan 2010 at 10:53

[GoogleCodeExporter]

Hi Greg,

LUT, yes, I'd like to take a look.

wrt jpeg2000 encoding perfomance: Might be that Fraunhofer licensed Taubman's 
Kakadu
(http://www.kakadusoftware.com/), see 
http://cuj2k.sourceforge.net/Benchmark.html for
comparisons.
I think CUDA-based encoders on off-the-shelf GPU's are lurking just around the
corner, we'll see.

Wolfgang Woehl

Original comment by photonra...@gmail.com on 30 Jan 2010 at 1:16