[Bf-committers] Color management broken?
Is there a reason that the color management transforms do not work on EXR files saves? Seems broken. With respect, TJS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color management broken?
Nothing is broken here. All the float images are saving in scene linear space by intention. Adding a way to save in different color space is in TODO list. On Mon, Jul 8, 2013 at 7:38 AM, Troy Sobotka wrote: > Is there a reason that the color management transforms do not work on EXR > files saves? > > Seems broken. > > With respect, > TJS > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color management broken?
On Jul 7, 2013 11:50 PM, "Sergey Sharybin" wrote: > Adding a way to save in different color space is in > TODO list. Would it not be the equivalent as to all of the other formats? If we use the "View as Render" option on a JPEG for example, it applies. On an EXR, it doesn't. Is it not reasonable to trust an artist to apply a correct transform? With respect, TJS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color management broken?
Sergey, It is crucial that the artist have the option to save EXRs with the color transform chain directed by the artist. Without this, it severely limits the ability to use EXR as a image interchange format between blender and other parts of the pipeline. Sincerely, Andrew On Mon, Jul 8, 2013 at 10:44 AM, Troy Sobotka wrote: > On Jul 7, 2013 11:50 PM, "Sergey Sharybin" wrote: > > > Adding a way to save in different color space is in > > TODO list. > > Would it not be the equivalent as to all of the other formats? > > If we use the "View as Render" option on a JPEG for example, it applies. > > On an EXR, it doesn't. > > Is it not reasonable to trust an artist to apply a correct transform? > > With respect, > TJS > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color management broken?
Toby, I'm not quite sure to understand what you are asking. You would like the color transform "baked-in" EXR ? IMO, exr should always be linear, especially if you have to move it around other parts of a pipeline. The ability to baked transform into a LUT seems more reasonable no ? 2013/7/8 Andrew Hunter > Sergey, > > It is crucial that the artist have the option to save EXRs with the color > transform chain directed by the artist. Without this, it severely limits > the ability to use EXR as a image interchange format between blender and > other parts of the pipeline. > > Sincerely, > > Andrew > > > On Mon, Jul 8, 2013 at 10:44 AM, Troy Sobotka >wrote: > > > On Jul 7, 2013 11:50 PM, "Sergey Sharybin" wrote: > > > > > Adding a way to save in different color space is in > > > TODO list. > > > > Would it not be the equivalent as to all of the other formats? > > > > If we use the "View as Render" option on a JPEG for example, it applies. > > > > On an EXR, it doesn't. > > > > Is it not reasonable to trust an artist to apply a correct transform? > > > > With respect, > > TJS > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- François Tarlier www.francois-tarlier.com www.linkedin.com/in/francoistarlier ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color management broken?
oups, meant Troy... (I'm talking to a Toby at teh same time :p ) 2013/7/9 François T. > Toby, I'm not quite sure to understand what you are asking. You would like > the color transform "baked-in" EXR ? IMO, exr should always be linear, > especially if you have to move it around other parts of a pipeline. The > ability to baked transform into a LUT seems more reasonable no ? > > > > > 2013/7/8 Andrew Hunter > >> Sergey, >> >> It is crucial that the artist have the option to save EXRs with the color >> transform chain directed by the artist. Without this, it severely limits >> the ability to use EXR as a image interchange format between blender and >> other parts of the pipeline. >> >> Sincerely, >> >> Andrew >> >> >> On Mon, Jul 8, 2013 at 10:44 AM, Troy Sobotka > >wrote: >> >> > On Jul 7, 2013 11:50 PM, "Sergey Sharybin" >> wrote: >> > >> > > Adding a way to save in different color space is in >> > > TODO list. >> > >> > Would it not be the equivalent as to all of the other formats? >> > >> > If we use the "View as Render" option on a JPEG for example, it applies. >> > >> > On an EXR, it doesn't. >> > >> > Is it not reasonable to trust an artist to apply a correct transform? >> > >> > With respect, >> > TJS >> > ___ >> > Bf-committers mailing list >> > Bf-committers@blender.org >> > http://lists.blender.org/mailman/listinfo/bf-committers >> > >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > > > -- > > François Tarlier > www.francois-tarlier.com > www.linkedin.com/in/francoistarlier > -- François Tarlier www.francois-tarlier.com www.linkedin.com/in/francoistarlier ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color management broken?
On Jul 9, 2013 5:48 AM, "François T." wrote: > > Troy, I'm not quite sure to understand what you are asking. You would like > the color transform "baked-in" EXR ? IMO, exr should always be linear, > especially if you have to move it around other parts of a pipeline. The > ability to baked transform into a LUT seems more reasonable no ? "Linear" is not a color space. There is more to a color space than the transfer / tone response curve. We could go into the details as to how to keep an EXR linear, but it would cascade into complexity. Banishing all color transforms on a file format is problematic. The bottom line is that it currently is impossible to shift the primaries of an EXR in any way. With respect, TJS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color management broken?
Yes I do agree, but I don't see why the transformation would happen at the EXR render. do you have a case ? 2013/7/9 Troy Sobotka > On Jul 9, 2013 5:48 AM, "François T." wrote: > > > > Troy, I'm not quite sure to understand what you are asking. You would > like > > the color transform "baked-in" EXR ? IMO, exr should always be linear, > > especially if you have to move it around other parts of a pipeline. The > > ability to baked transform into a LUT seems more reasonable no ? > > "Linear" is not a color space. There is more to a color space than the > transfer / tone response curve. > > We could go into the details as to how to keep an EXR linear, but it would > cascade into complexity. Banishing all color transforms on a file format is > problematic. > > The bottom line is that it currently is impossible to shift the primaries > of an EXR in any way. > > With respect, > TJS > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- François Tarlier www.francois-tarlier.com www.linkedin.com/in/francoistarlier ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color management broken?
On Jul 9, 2013 8:23 AM, "François T." wrote: > > Yes I do agree, but I don't see why the transformation would happen at the > EXR render. do you have a case ? Any time you need to shift primaries. Examples might include: *) AdobeRGB images from a DSLR converted to sRGB for textures. *) sRGB primaries to XYZ primaries. *) sRGB to ACES. Etc. Etc. Etc. Etc. With respect, TJS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color management broken?
Deep compositing in Nuke in ACES. On Jul 9, 2013 11:22 AM, "François T." wrote: > Yes I do agree, but I don't see why the transformation would happen at the > EXR render. do you have a case ? > > > 2013/7/9 Troy Sobotka > > > On Jul 9, 2013 5:48 AM, "François T." wrote: > > > > > > Troy, I'm not quite sure to understand what you are asking. You would > > like > > > the color transform "baked-in" EXR ? IMO, exr should always be linear, > > > especially if you have to move it around other parts of a pipeline. The > > > ability to baked transform into a LUT seems more reasonable no ? > > > > "Linear" is not a color space. There is more to a color space than the > > transfer / tone response curve. > > > > We could go into the details as to how to keep an EXR linear, but it > would > > cascade into complexity. Banishing all color transforms on a file format > is > > problematic. > > > > The bottom line is that it currently is impossible to shift the primaries > > of an EXR in any way. > > > > With respect, > > TJS > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > -- > > François Tarlier > www.francois-tarlier.com > www.linkedin.com/in/francoistarlier > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color management broken?
As a wise man said: go deeper! The actual issue is not about being unable to apply any sort of color transform when saving float buffer (which you shouldn't do btw in properly set pipeline). The root of the issue goes to the fact, that renderer always outputs stuff in rec709 space (or in your language it'll be linear space with rec709 primaries). And this is what need to be solved, so renderer will also work in actual scene linear space. Once it's done you'll just make it so all the software involved into your pipeline uses the same scene linear space, same primaries and so and so on. Saving will go naturally fine without requiring any kind of extra color space conversions. On Wed, Jul 10, 2013 at 1:32 AM, Andrew Hunter wrote: > Deep compositing in Nuke in ACES. > On Jul 9, 2013 11:22 AM, "François T." wrote: > > > Yes I do agree, but I don't see why the transformation would happen at > the > > EXR render. do you have a case ? > > > > > > 2013/7/9 Troy Sobotka > > > > > On Jul 9, 2013 5:48 AM, "François T." > wrote: > > > > > > > > Troy, I'm not quite sure to understand what you are asking. You would > > > like > > > > the color transform "baked-in" EXR ? IMO, exr should always be > linear, > > > > especially if you have to move it around other parts of a pipeline. > The > > > > ability to baked transform into a LUT seems more reasonable no ? > > > > > > "Linear" is not a color space. There is more to a color space than the > > > transfer / tone response curve. > > > > > > We could go into the details as to how to keep an EXR linear, but it > > would > > > cascade into complexity. Banishing all color transforms on a file > format > > is > > > problematic. > > > > > > The bottom line is that it currently is impossible to shift the > primaries > > > of an EXR in any way. > > > > > > With respect, > > > TJS > > > ___ > > > Bf-committers mailing list > > > Bf-committers@blender.org > > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > > > > > > -- > > > > François Tarlier > > www.francois-tarlier.com > > www.linkedin.com/in/francoistarlier > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color management broken?
On Jul 9, 2013 1:15 PM, "Sergey Sharybin" wrote: >The root of the issue goes to the fact, that renderer always > outputs stuff in rec709 space (or in your language it'll be linear space > with rec709 primaries). ? The renderer only renders with the values assigned, no? Given that out color picker has yet to get proper management, this still seems like a curious statement given that we can color light to any value under assumed primaries? With respect, TJS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color management broken?
No idea what exactly "only renders with the values assigned" means. Renderers (at least current ones) indeed works with RGB colors with premultiplied alpha (and premultiplied is the term we stick here to). Render engine should be a black box for the pipeline actually, it could use any color space, any alpha mode it wants to. But when result goes out from the engine to the pipeline it shall stick to current color management. Which means if Scene Linear is set to ACES, render result need to be converted to ACES space before it's used in compositor or getting saved to the file. Color picker is also kind of an issue, but it's not as much biggie. Currently it's just using some kind of approximation of ColorPicker space by assuming default View of display transform is always invertible and uses it for picking the color. Works reasonably fine, and does not bother normal artists being with extra options which are just confusing for 95% of blender artists. Agree those are indeed bigger tasks (comparing with just adding color space conversion on file save), but we don't choose easy way, we d choose the right way. And this issues are not so much high priority for general blender development, but if someone volunteers to solve them (and solve in a proper way, not hackish one) he'll be for sore welcome. On Wed, Jul 10, 2013 at 6:10 AM, Troy Sobotka wrote: > On Jul 9, 2013 1:15 PM, "Sergey Sharybin" wrote: > >The root of the issue goes to the fact, that renderer always > > outputs stuff in rec709 space (or in your language it'll be linear space > > with rec709 primaries). > > ? > > The renderer only renders with the values assigned, no? > > Given that out color picker has yet to get proper management, this still > seems like a curious statement given that we can color light to any value > under assumed primaries? > > With respect, > TJS > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color management broken?
Hi Sergey, On Jul 10, 2013 4:34 AM, "Sergey Sharybin" wrote: > > Render engine should be a black box for the pipeline actually, it could use > any color space, any alpha mode it wants to. But when result goes out from > the engine to the pipeline it shall stick to current color management. Could you clarify what you mean my this? > Which means if Scene Linear is set to ACES, render result need to be > converted to ACES space before it's used in compositor or getting saved to > the file. If the render result needs to be converted to ACES, then the renderer is not a black box if scene linear is ACES. Am I misunderstanding what you are saying? > Color picker is also kind of an issue, but it's not as much biggie. > Currently it's just using some kind of approximation of ColorPicker space > by assuming default View of display transform is always invertible and uses > it for picking the color. Works reasonably fine, and does not bother normal > artists being with extra options which are just confusing for 95% of > blender artists. "normal" is contextual. > Agree those are indeed bigger tasks (comparing with just adding color space > conversion on file save), but we don't choose easy way, we d choose the > right way. As I understand it, Exr renders from blender are unsuitable for exchange with other applications without first taking into account the peculiar notion that float buffers must be saved to disk untransformed. That isn't what I would call the "right" way. > > On Wed, Jul 10, 2013 at 6:10 AM, Troy Sobotka wrote: > > > On Jul 9, 2013 1:15 PM, "Sergey Sharybin" wrote: > > >The root of the issue goes to the fact, that renderer always > > > outputs stuff in rec709 space (or in your language it'll be linear space > > > with rec709 primaries). > > > > ? > > > > The renderer only renders with the values assigned, no? > > > > Given that out color picker has yet to get proper management, this still > > seems like a curious statement given that we can color light to any value > > under assumed primaries? > > > > With respect, > > TJS > > ___ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > -- > With best regards, Sergey Sharybin > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color management broken?
Answers are inlined. On Sat, Jul 13, 2013 at 10:21 PM, Andrew Hunter wrote: > Hi Sergey, > > On Jul 10, 2013 4:34 AM, "Sergey Sharybin" wrote: > > > > Render engine should be a black box for the pipeline actually, it could > use > > any color space, any alpha mode it wants to. But when result goes out > from > > the engine to the pipeline it shall stick to current color management. > > Could you clarify what you mean my this? > It means blender part of render pipeline shouldn't know in which space render engine itself is working. it's only matter of agreeing i which space render [partial] result is passing from the engine to blender. Couple of ways here: - Either render engine itself bothers with converting stuff to Scene Linear (this is the most flexible way which i initially thought of, which makes tihngs behave as real pitch-black box, but requires all the engines to worry about this stuff which is not so much nice) - Provides color space to the blender via some api (this way we still supports engines which could potentiall work in different spaces) - Renderer's color space is defined as a role in OCIO config. This way renderer is not technically speaking a black-box, but this requires no changes to the render engines and it's still enough of control over the color pipeline. - It could also be a per-engine role or colorspace defined in blender itself, so different engines could have different spaces. But in fact i don' think supporting different spaces for different engines working at the same is crucial. It's unlikely you'll mix different renderers on the same pipeline. So i would think of ocio.config-defined rendreer's color space is the way to go. You'll just have different configs for different projects (if needed ofcourse, you could use the same config if there're no differences in color pipelines). > > > Which means if Scene Linear is set to ACES, render result need to be > > converted to ACES space before it's used in compositor or getting saved > to > > the file. > > If the render result needs to be converted to ACES, then the renderer is > not a black box if scene linear is ACES. Am I misunderstanding what you are > saying? > At this point it's not so much clear who would actually do a conversion: engine itself or blender's side of pipeline, or some api or whatever else. See above. But the thing is: image buffer in render result structure shall always be in scene linear space. > > > Color picker is also kind of an issue, but it's not as much biggie. > > Currently it's just using some kind of approximation of ColorPicker space > > by assuming default View of display transform is always invertible and > uses > > it for picking the color. Works reasonably fine, and does not bother > normal > > artists being with extra options which are just confusing for 95% of > > blender artists. > > "normal" is contextual. > Yes. And context is clear enough from the mailing list. If some option is only used by few commercial studios and which keeps rest of the smaller studios and other blender artists just confused -- it's rather bad option. Now, if you'll add color picker space, what would you set it to? And whether/how do change it when someone changes current display/view? This is rather rhetorical questions for now and i don't want to discuss them for until someone is gonna to implement this feature. But keep in mind: if changing one option (which is display/view) requires changing other things (which is color picker space) to just keep behavior sane, it's rather counter-intuitive and confusing. There're also couple of ways to deal with this. Like, using either some "default" choose which will have current behavior and allow to choose other color space if needed. Or try to somehow approximate which colorspace fits best current display and so. > > > Agree those are indeed bigger tasks (comparing with just adding color > space > > conversion on file save), but we don't choose easy way, we d choose the > > right way. > > As I understand it, Exr renders from blender are unsuitable for exchange > with other applications without first taking into account the peculiar > notion that float buffers must be saved to disk untransformed. > > That isn't what I would call the "right" way. > All the software in a pipeline shall be configured in a way they work with the same color space settings. For exrs which are used for interchange they shall be saved in Scene Linear space. So this way you just configure blender and whatever-else-software to use the same ocio.config (which is the whole idea of ocio library btw) and you wouldn't need to ensure you're saving stuff in the proper space from blender. It's probably still would need to support color space transform on save, but that's rather and exceptional case and wouldn't give it a high priority. > > > > > On Wed, Jul 10, 2013 at 6:10 AM, Troy Sobotka >wrote: > > > > > On Jul 9, 2013 1:15 PM, "Sergey Sharybin" > wrote: > > > >The root of the issue go
