Date   

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

 


Re: Problems with displaying exposure

Andrew Hunter <and...@...>
 

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.

Cheers,

Andrew

On Nov 19, 2012 4:29 AM, "Boudewijn Rempt" <bo...@...> wrote:
Hi,

I've got some problems using the code from the ocio display application in Krita, and I'm not sure what's going on. The problem is that when the exposure gets negative, the image gets more transparent, and I cannot figure out why that should be...
--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl


Re: parsing configs with non-C locale

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

On 11/19/2012 8:28 AM, Dithermaster wrote:
Ben's description aligns with my own experiences. We had a similar bug
reading/writing a text file with decimals, and fixed it in a similar way
(by saving/setting/restoring the locale setting).
Same here. But in that case, rather than fiddling with the locale (I wasn't sure of any unintended consequences of doing that), I swapped in a custom sscanf() that assumed decimal separators.

Still, I'll manually swap into the C locale when using OCIO in my imminent update, but I agree it should probably be done inside OCIO at some point. One less implementation detail to worry about.


Re: parsing configs with non-C locale

Dithermaster <dither...@...>
 

Ben's description aligns with my own experiences. We had a similar bug reading/writing a text file with decimals, and fixed it in a similar way (by saving/setting/restoring the locale setting).

///d@


On Nov 19, 2012, at 6:54 AM, dbr/Ben <dbr....@...> wrote:

I've not had much experience with locales either, but it seemed like an interesting thing to read up on.. so..

With LANG=de_DE, sscanf expects to see floats like "0,12" (compared to 0.12 as required in the LUT file)

Doesn't happen often because the locale defaults to "C", and the user's environment is ignored unless setlocale() has been called elsewhere in the process:


I think OCIO should definitely set the locale to "C" temporarily while parsing/writing files, otherwise it might end up with invalid LUT's that happen to work for the current user but no-one else..

Based on this page..
..I think the tidiest way to fix this would be:

- Replace the few usages of the C string-parsing methods (sscanf/atof/etc) with the C++ stdlib equivalents (the *stream stuff)
- Modify FileTransform.cpp:GetFile to imbue the filestream with the "C" locale (as described in the above apache.org link)
- Same imbue'ing wherever else std::ofstream or std::ifstream is used (not many places - main ones are FileTransform, ociobakelut, and the CDLTransform)

I think that should make the reading/writing of files locale-independant, but there might still be other issues..? (e.g the stringstream used to construct exception messages)

Python has a kind of similar problem, seems like their approach was to write their own atof/stdtod methods, but I don't think this will work for OCIO, since it mainly uses the C++ *stream stuff..

On 17/11/2012, at 2:46 AM, Jeremy Selan wrote:

Hm...

I have to admit I dont have much experience with locales.  Can someone
with experience on such issues please comment?  On first glance, it
feels like it should certainly be fixed inside OCIO, but perhaps I am
mistaken?

-- Jeremy

On Thu, Nov 15, 2012 at 7:01 AM, Paul Miller <pa...@...> wrote:
I think I found a bug in either my code or OCIO. When our software is run on
a Ubuntu 12.04 machine with a German locale, parsing of srgb.spi1d fails and
we get an "Invalid 'From' Tag" exception. I think the sscanf() there is
attempting to parse the string using the German locale. Should I be forcing
the C locale before calling into OCIO, or should OCIO be doing this itself?


Re: parsing configs with non-C locale

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

I've not had much experience with locales either, but it seemed like an interesting thing to read up on.. so..

With LANG=de_DE, sscanf expects to see floats like "0,12" (compared to 0.12 as required in the LUT file)

Doesn't happen often because the locale defaults to "C", and the user's environment is ignored unless setlocale() has been called elsewhere in the process:


I think OCIO should definitely set the locale to "C" temporarily while parsing/writing files, otherwise it might end up with invalid LUT's that happen to work for the current user but no-one else..

Based on this page..
..I think the tidiest way to fix this would be:

- Replace the few usages of the C string-parsing methods (sscanf/atof/etc) with the C++ stdlib equivalents (the *stream stuff)
- Modify FileTransform.cpp:GetFile to imbue the filestream with the "C" locale (as described in the above apache.org link)
- Same imbue'ing wherever else std::ofstream or std::ifstream is used (not many places - main ones are FileTransform, ociobakelut, and the CDLTransform)

I think that should make the reading/writing of files locale-independant, but there might still be other issues..? (e.g the stringstream used to construct exception messages)

Python has a kind of similar problem, seems like their approach was to write their own atof/stdtod methods, but I don't think this will work for OCIO, since it mainly uses the C++ *stream stuff..

On 17/11/2012, at 2:46 AM, Jeremy Selan wrote:

Hm...

I have to admit I dont have much experience with locales.  Can someone
with experience on such issues please comment?  On first glance, it
feels like it should certainly be fixed inside OCIO, but perhaps I am
mistaken?

-- Jeremy

On Thu, Nov 15, 2012 at 7:01 AM, Paul Miller <pa...@...> wrote:
I think I found a bug in either my code or OCIO. When our software is run on
a Ubuntu 12.04 machine with a German locale, parsing of srgb.spi1d fails and
we get an "Invalid 'From' Tag" exception. I think the sscanf() there is
attempting to parse the string using the German locale. Should I be forcing
the C locale before calling into OCIO, or should OCIO be doing this itself?


Problems with displaying exposure

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

Hi,

I've got some problems using the code from the ocio display application in Krita, and I'm not sure what's going on. The problem is that when the exposure gets negative, the image gets more transparent, and I cannot figure out why that should be...
--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl


Re: parsing configs with non-C locale

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

Hm...

I have to admit I dont have much experience with locales. Can someone
with experience on such issues please comment? On first glance, it
feels like it should certainly be fixed inside OCIO, but perhaps I am
mistaken?

-- Jeremy

On Thu, Nov 15, 2012 at 7:01 AM, Paul Miller <pa...@...> wrote:
I think I found a bug in either my code or OCIO. When our software is run on
a Ubuntu 12.04 machine with a German locale, parsing of srgb.spi1d fails and
we get an "Invalid 'From' Tag" exception. I think the sscanf() there is
attempting to parse the string using the German locale. Should I be forcing
the C locale before calling into OCIO, or should OCIO be doing this itself?


parsing configs with non-C locale

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

I think I found a bug in either my code or OCIO. When our software is run on a Ubuntu 12.04 machine with a German locale, parsing of srgb.spi1d fails and we get an "Invalid 'From' Tag" exception. I think the sscanf() there is attempting to parse the string using the German locale. Should I be forcing the C locale before calling into OCIO, or should OCIO be doing this itself?

1141 - 1160 of 2226