Date   

Re: Rendering per-shot grades with ocioconvert

bsloan <bsl...@...>
 

Thanks all. Yes, I was able to get the desired result by add a colorspace to the config that applies the grade and the display LUT.

We're trying ocioconvert as a way to make LUT-baked jpeg proxies of EDR renders. Nuke, burdened with our facility customizations is too slow to launch per-frame and rvio is too expensive. For a shop that has an OCIO config dir and per-shot grades for every show, ocioconvert looks more like a free, off-the-shelf tool than an API tutorial.

:)



On Tuesday, December 4, 2012 2:59:08 PM UTC-8, bsloan wrote:
Apologies if this is a repeat question:

Ocioconvert takes an input and output colorspace from the current ocio.config and applies a transform to an input image.

Is it possible to apply a look as well? Would that require adding a colorspace to ocio.config? Or is it even possible?

Also, ocioconvert in ocio 1.0.7 appears to be not very well documented. 

Nag, nag nag.

Thanks again, 

-blake

--
--transcribed from fMRI data using Google Thought Engine


.ICC not requiring --copyright info

Andrew Britton <andrew.d...@...>
 

I've been building various .ICC files and not once have I set the --copyright flag and not once has an error been thrown. After looking in the main.cpp for ociobakelut I see that it should be throwing an error, but for some reason it isn't. Is it being set by default in the Argparse class?

Andrew


Re: Rendering per-shot grades with ocioconvert

Brendan Bolles <bre...@...>
 

On Dec 4, 2012, at 2:59 PM, Blake Sloan wrote:

Is it possible to apply a look as well? Would that require adding a colorspace to ocio.config? Or is it even possible?

If you look at the spi-vfx configuration, the srgb8 and p3dci8 color spaces incorporate a film look using a 3D LUT. That's why you can use them as an output space but not an input space (the 3D LUT can't be inverted). To do different 3D LUTs for different shots with the software as it currently is, you could create a whole bunch of output color spaces (srgb8-shot1, srgb8-shot2, etc.) as Ben is suggesting.

OCIO has the ability to add a separate "looks" parameter via DisplayTransform.setLooksOverride() and other mechanisms, but none of the current software is using it and none of the sample configs have looks. I'm kind of surprised by that actually - does Sony not use per-shot color corrections and looks?


Brendan


Re: Rendering per-shot grades with ocioconvert

dbr/Ben <dbr....@...>
 

It would be easy to add an "ocioconvert --look blah" argument. Made a ticket for that:


I think ocioconvert is mainly intended as an example of how to use the OCIO API (as is ociodisplay), and facilities would tend to have their own comperable tool.. so it's not necessarily updated with new features (unless they are requested, as you have done!)

That is also one of the reasons there's quite so little documentation on it (along with the usual reasons for lack of documentation!). Ticket for that:


As for a workaround, you could define a colorspace which applies your look, something like:

colorspaces:
  - !<ColorSpace>
    name: lookworkaround
    to_reference: !<GroupTransform>
      children:
        - !<LookTransform> {src: lnf, dst: lnf, looks: "maingradelook,secondlook"}
        - !<FileTransform> {src: blah.spi3d, interpolation: linear}
        - !<ColorSpaceTransform> {src: lnf, dst: lg10}

Then do:
$ ocioconvert in.exr lnf out.exr lookworkaround

(haven't tested the above ColorSpace, and it's been months since I've written a config, but that should give you the general idea..)


On 05/12/2012, at 9:29 AM, Blake Sloan wrote:

Apologies if this is a repeat question:

Ocioconvert takes an input and output colorspace from the current ocio.config and applies a transform to an input image.

Is it possible to apply a look as well? Would that require adding a colorspace to ocio.config? Or is it even possible?

Also, ocioconvert in ocio 1.0.7 appears to be not very well documented. 

Nag, nag nag.

Thanks again, 

-blake

--
--transcribed from fMRI data using Google Thought Engine

--
 
 


Rendering per-shot grades with ocioconvert

Blake Sloan <bsl...@...>
 

Apologies if this is a repeat question:

Ocioconvert takes an input and output colorspace from the current ocio.config and applies a transform to an input image.

Is it possible to apply a look as well? Would that require adding a colorspace to ocio.config? Or is it even possible?

Also, ocioconvert in ocio 1.0.7 appears to be not very well documented. 

Nag, nag nag.

Thanks again, 

-blake

--
--transcribed from fMRI data using Google Thought Engine


Re: SceneLinear to LogC into an ICC profile

Kai-Uwe Behrmann <ku...@...>
 

Am 04.12.2012 02:27, schrieb Brendan Bolles:
Copyright is more optional, I think.
It is not.

If no description is provided, we could also use the output file name, but there definitely should be a description. I'm surprised lcms doesn't throw an error when the description is set to an empty string.
Filename == description is a good assumtion at profile write time.

kind regards
Kai-Uwe
--
www.oyranos.org


Re: SceneLinear to LogC into an ICC profile

Jeremy Selan <jeremy...@...>
 

Added for tracking. Should be easy to fix. Sorry for not catching this sooner.

https://github.com/imageworks/OpenColorIO/issues/291

On Mon, Dec 3, 2012 at 5:27 PM, Brendan Bolles <bre...@...> wrote:
On Dec 3, 2012, at 4:19 PM, Andrew Britton wrote:

I've solved the error of Photoshop (ver12.1 x64), for PC, not recognizing my ICC files. In my attempts to convert a LUT to an .ICC file I was originally forgetting to include the "--description" flag. Once this flag was included, I was able to read in the profile to Photoshop and assign it to an image.
I figured this may be useful to someone else.

I'd call that a bug. Currently ociobakelut gives an error you don't provide a copyright, but it should really give an error if there's no description. Copyright is more optional, I think.

If no description is provided, we could also use the output file name, but there definitely should be a description. I'm surprised lcms doesn't throw an error when the description is set to an empty string.


Brendan

--


Re: SceneLinear to LogC into an ICC profile

Brendan Bolles <bre...@...>
 

On Dec 3, 2012, at 4:19 PM, Andrew Britton wrote:

I've solved the error of Photoshop (ver12.1 x64), for PC, not recognizing my ICC files. In my attempts to convert a LUT to an .ICC file I was originally forgetting to include the "--description" flag. Once this flag was included, I was able to read in the profile to Photoshop and assign it to an image.
I figured this may be useful to someone else.

I'd call that a bug. Currently ociobakelut gives an error you don't provide a copyright, but it should really give an error if there's no description. Copyright is more optional, I think.

If no description is provided, we could also use the output file name, but there definitely should be a description. I'm surprised lcms doesn't throw an error when the description is set to an empty string.


Brendan


Re: SceneLinear to LogC into an ICC profile

Andrew Britton <cbsd....@...>
 

I've solved the error of Photoshop (ver12.1 x64), for PC, not recognizing my ICC files. In my attempts to convert a LUT to an .ICC file I was originally forgetting to include the "--description" flag. Once this flag was included, I was able to read in the profile to Photoshop and assign it to an image.
I figured this may be useful to someone else.

Thanks for everyone's help thus far.


Re: 最新112届 2012秋季广交会买家,B2B询盘买家、thomasnet 采购商,海关数据,群发软件,展会买家 仅300元!

Jeremy Selan <jeremy...@...>
 

Sorry about the spam, folks!

This is what happens when I'm still jetlagged and try to take care of online work at 5 AM. ;)

-- Jeremy


On Sunday, December 2, 2012 5:41:43 AM UTC-8, Simon Legrand wrote:
And so the Chinese cyber terrorism unit has finally worked out that we were a major threat to the party. All this talk of BRDF shading must have scared them. :)



Re: 最新112届 2012秋季广交会买家,B2B询盘买家、thomasnet 采购商,海关数据,群发软件,展会买家 仅300元!

Simon Legrand <legran...@...>
 

And so the Chinese cyber terrorism unit has finally worked out that we were a major threat to the party. All this talk of BRDF shading must have scared them. :)



2022/11/29 有效果再付款 <ad...@...>


最新112届 2012秋季广交会买家,海关数据提单piers版,2008-2012年9届广交会数据。

一共10个包(数据是全行业的,可以按照关键词提取出来的):
1,2012春季112届广交会买家现场询盘数据库新鲜出炉,超级新鲜买家,新鲜数据,容易成单!
2,购买后可以免费更新2012秋季广交会买家数据。太超值了。
3,2012最新全球展会现场买家库(与贸发同步),共46万条数据。 (按照行业分类)
4,2012,2011,2010年,2009年,2008年 春季+秋季广交会买家名录,103 104 105 106 107 108,109,110,111 共7届 共150.6万数据。
5,48.68万条最新买家询盘,都带有Email,最有价值的询盘。
6,2011最新 B2B 英文国际站60万带联络方式询盘 最有价值询盘之一.
7,2010海关提单piers版1000万数据.
8,2011年到香港采购的国外客人名录(香港贸发局提供),超级重要的买家。
9,2011年新增加的-美国B2B thomasnet 采购商名单。
10,群发软件安装与部署服务。

这些全有,共1360万 买家。


要的抓紧联系QQ: 1711744329  或者立即回复邮箱: 17117...@...
要的抓紧联系QQ: 1711744329  或者立即回复邮箱: 17117...@...
要的抓紧联系QQ: 1711744329  或者立即回复邮箱: 17117...@...

诚信为本,如果不信任本人,可以走支付宝担保交易,收到数据验证3天后再付款,这是对您最好的保障了。



小技巧:
把1360万买家群发以一遍,均会有数千个回复的,这些就是非常高质量的买家。
使用我们送的群发软件,1-2周就可完全发完。





广交会买家按产品类别分类,分为以下几类:
1 办公设备
2 编织及藤铁工艺品
3 玻璃
4 餐厨用具
5 车辆
6 大型机械及设备
7 电子电气
8 电子消费品
9 纺织
10 服装
11 个人护理
12 工程机械
13 工具
14 化工
15 计算机及通讯
16 家居用品
17 家居装饰
18 家具
19 家用电器
20 建筑及装饰材料
21 节日用品
22 礼品及赠品
23 摩托车
24 汽车配件
25 食品
26 陶瓷
27 铁石
28 玩具
29 卫浴
30 五金
31 小型机械
32 鞋
33 休闲用品
34 医疗
35 浴室产品
36 园林
37 照明产品
38 钟表眼镜
39 自行车
40 包


新鲜数据-成单率极高
新鲜数据-成单率极高
新鲜数据-成单率极高
新鲜数据-成单率极高
新鲜数据-成单率极高





Re: SceneLinear to LogC into an ICC profile

Kai-Uwe Behrmann <ku...@...>
 

There are at least two open source CMM's around, which support float style lookup tables. One is used in Krita, which in turn links to OCIO.
The involved Lcms CMM has since version 2.4 a option to apply pre and post linearisation curves to ICC transforms, which greatly improves linear to gamma conversion quality.

kind regards
Kai-Uwe
--
www.oyranos.org

Am 29.11.2012 14:35, schrieb dbr/Ben:

The --inputspace/--outputspace arguments are only required when using an OCIO config. The --lut argument is used, alone, for "Config-free baking":

http://opencolorio.org/userguide/baking_luts.html#config-free-baking

So you would just do something like:

ociobakelut --lut ln_1_logC.3dl --format icc mynewlut.icc

..which will make an ICC which applies the same transform as the 3dl.


However, I suspect there's a bigger problem with what you are trying to do - the .3dl and .icc profiles don't tend to work well with scene-linear values:

- 3dl only works with integer values (usually print-denstity-space scans or Rec709 video), it would clamp scene-linear values over 1.0 (to about 0.6 in LogC)

- ICC probably can, there was an update to the ICC spec to support their equivalent to a floating-point shaper LUT ("unbounded Device-side encoding"?)

http://www.color.org/ICCSpecRevision_02_11_06_Float.pdf

However this requires that the host application supports that version of ICC (Photoshop CS4 doesn't, and pretty sure neither does CS5). Also I'd guess OCIO's baker would need updated also.

On 28/11/2012, at 12:52 PM, Andrew Britton wrote:

A question about converting from scene linear to ARRI LogC via an icc profile:

when I use ociobakelut I'm wondering how to create an icc file that will be a viewing profile for a scenelinear image, to view it in LogC. My assumptions are as follows with a question about the direction of a LUT.

First I'm assuming this will be the proper command for creating said ICC profile:
ociobakelut --inputspace lnf --lut ln_2_logC.3dl --format icc /path/finalPath/LogC_Viewer.icc

So the question I have when making the ln_2_logC.3dl is which direction should the LUT be created? ie... should the .cube be created to convert from SceneLinear to LogC or vice versa? My apologies if this seems obvious, and my assumption is that the .cube should be from SceneLinear to LogC, but I'm confused as to why there would need to be an --inputspace predefined if it's already in the .3dl LUT. In this case of converting a .3dl to a .icc, I would expect the command to only need one .3dl file.

Thank you,
Andrew


Re: SceneLinear to LogC into an ICC profile

dbr/Ben <dbr....@...>
 

The --inputspace/--outputspace arguments are only required when using an OCIO config. The --lut argument is used, alone, for "Config-free baking":


So you would just do something like:

ociobakelut --lut ln_1_logC.3dl --format icc mynewlut.icc

..which will make an ICC which applies the same transform as the 3dl.


However, I suspect there's a bigger problem with what you are trying to do - the .3dl and .icc profiles don't tend to work well with scene-linear values:

- 3dl only works with integer values (usually print-denstity-space scans or Rec709 video), it would clamp scene-linear values over 1.0 (to about 0.6 in LogC)

- ICC probably can, there was an update to the ICC spec to support their equivalent to a floating-point shaper LUT ("unbounded Device-side encoding"?)


However this requires that the host application supports that version of ICC (Photoshop CS4 doesn't, and pretty sure neither does CS5). Also I'd guess OCIO's baker would need updated also.

On 28/11/2012, at 12:52 PM, Andrew Britton wrote:

A question about converting from scene linear to ARRI LogC via an icc profile:

when I use ociobakelut I'm wondering how to create an icc file that will be a viewing profile for a scenelinear image, to view it in LogC. My assumptions are as follows with a question about the direction of a LUT.

First I'm assuming this will be the proper command for creating said ICC profile:
ociobakelut --inputspace lnf --lut ln_2_logC.3dl --format icc /path/finalPath/LogC_Viewer.icc

So the question I have when making the ln_2_logC.3dl is which direction should the LUT be created? ie... should the .cube be created to convert from SceneLinear to LogC or vice versa? My apologies if this seems obvious, and my assumption is that the .cube should be from SceneLinear to LogC, but I'm confused as to why there would need to be an --inputspace predefined if it's already in the .3dl LUT. In this case of converting a .3dl to a .icc, I would expect the command to only need one .3dl file.

Thank you,
Andrew


SceneLinear to LogC into an ICC profile

Andrew Britton <cbsd....@...>
 

A question about converting from scene linear to ARRI LogC via an icc profile:

when I use ociobakelut I'm wondering how to create an icc file that will be a viewing profile for a scenelinear image, to view it in LogC. My assumptions are as follows with a question about the direction of a LUT.

First I'm assuming this will be the proper command for creating said ICC profile:
ociobakelut --inputspace lnf --lut ln_2_logC.3dl --format icc /path/finalPath/LogC_Viewer.icc

So the question I have when making the ln_2_logC.3dl is which direction should the LUT be created? ie... should the .cube be created to convert from SceneLinear to LogC or vice versa? My apologies if this seems obvious, and my assumption is that the .cube should be from SceneLinear to LogC, but I'm confused as to why there would need to be an --inputspace predefined if it's already in the .3dl LUT. In this case of converting a .3dl to a .icc, I would expect the command to only need one .3dl file.

Thank you,
Andrew


Re: Problems with displaying exposure

Boudewijn Rempt <bo...@...>
 

On Sunday 25 November 2012 Nov, Boudewijn Rempt wrote:
On Saturday 24 November 2012 Nov, Paul Miller wrote:
On 11/24/2012 2:47 PM, Brendan Bolles wrote:
On Nov 24, 2012, at 12:19 PM, Brendan Bolles wrote:

Looks like a known issue. MatrixOps.cpp line 457 says:

Or I guess in ociodisplay/main.cpp you could change line 480 to read:

const float slope4f[] = { gain, gain, gain, 1.0f };


Not sure what effect it might have on channel swizzling.
I made this change recently after customer feedback. Seems to do the
job, and nobody has complained yet.
Cool, I will try that. Maybe it's something that can be part of the next release? It doesn't matter for the binaries I build and redistribute myself, but for Linux distributions carrying Krita, it's a problem: they don't want to have patched 3rd party libraries in an application.
Ah, I thought it was a patch to the library -- I was looking in the wrong place. I've fixed this in krita itself now and everything is fine! Thanks for the replies.


--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl


Re: Problems with displaying exposure

Boudewijn Rempt <bo...@...>
 

On Saturday 24 November 2012 Nov, Paul Miller wrote:
On 11/24/2012 2:47 PM, Brendan Bolles wrote:
On Nov 24, 2012, at 12:19 PM, Brendan Bolles wrote:

Looks like a known issue. MatrixOps.cpp line 457 says:

Or I guess in ociodisplay/main.cpp you could change line 480 to read:

const float slope4f[] = { gain, gain, gain, 1.0f };


Not sure what effect it might have on channel swizzling.
I made this change recently after customer feedback. Seems to do the
job, and nobody has complained yet.
Cool, I will try that. Maybe it's something that can be part of the next release? It doesn't matter for the binaries I build and redistribute myself, but for Linux distributions carrying Krita, it's a problem: they don't want to have patched 3rd party libraries in an application.

--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl


Re: Problems with displaying exposure

Paul Miller <pa...@...>
 

On 11/24/2012 2:47 PM, Brendan Bolles wrote:
On Nov 24, 2012, at 12:19 PM, Brendan Bolles wrote:

Looks like a known issue. MatrixOps.cpp line 457 says:

Or I guess in ociodisplay/main.cpp you could change line 480 to read:

const float slope4f[] = { gain, gain, gain, 1.0f };


Not sure what effect it might have on channel swizzling.
I made this change recently after customer feedback. Seems to do the job, and nobody has complained yet.


Re: Problems with displaying exposure

Brendan Bolles <bre...@...>
 

On Nov 24, 2012, at 12:19 PM, Brendan Bolles wrote:

Looks like a known issue. MatrixOps.cpp line 457 says:

Or I guess in ociodisplay/main.cpp you could change line 480 to read:

const float slope4f[] = { gain, gain, gain, 1.0f };


Not sure what effect it might have on channel swizzling.


Brendan


Re: Problems with displaying exposure

Brendan Bolles <bre...@...>
 

On Nov 24, 2012, at 5:05 AM, Boudewijn Rempt wrote:

I must be missing something else.

Looks like a known issue. MatrixOps.cpp line 457 says:

// TODO: This should not act upon alpha,
// since we dont apply it on the CPU?


Maybe you could figure out a way to keep the alpha multiplied by 1.0?



Brendan


Re: Problems with displaying exposure

Boudewijn Rempt <bo...@...>
 

On Thursday 22 November 2012 Nov, Andrew Hunter wrote:

> Hey Boudewijn,

>

> Sounds like the exposure function affecting the alpha channel. Alpha is

> usually normalized to 0 - 1, so it would make sense if positive exposure

> adjustments are clamped.

 

Yes -- that's what I figured. Unfortunately, I don't know why -- or rather, I don't know why that doesn't happen with the ocio display demo app. The code in Krita is pretty much the same, down to the same generated LUT -- and the shader calls the OCIODisplay method to calculate the color:

 

const char * m_fragShaderText = ""

"\n"

"uniform sampler2D tex1;\n"

"uniform sampler3D tex2;\n"

"\n"

"void main()\n"

"{\n"

" vec4 col = texture2D(tex1, gl_TexCoord[0].st);\n"

" gl_FragColor = OCIODisplay(col, tex2);\n"

"}\n"

 

I must be missing something else.

--

Boudewijn Rempt

http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl

 

1141 - 1160 of 2233