<font><font face="trebuchet ms,sans-serif">lots of chitchat for a known issue which as been there for ages ^^. So much chat that I actually lost what was the point of all this (and yet I did follow the discussion from the beginning). </font></font><div>
<font face="'trebuchet ms', sans-serif">Plus since you concentrate color space on standards and known ones. but with many cameras/hardwares comes LUT as well. So its not just about converting a few spaces to another of the one we know as for today. And for sure its not just an issue around the Sony Camera. Think about 5D and its cinestyle LUT, or C300 and all its profiles ? yes those are not color space, yet transformation very good to use</font></div>
<div><font face="'trebuchet ms', sans-serif">A popular CM engine with lots of LUTs is already there. it let you do any transformation. Why is there still some arguments on the topic there ? I honestly don't follow anymore. </font></div>
<div><font face="'trebuchet ms', sans-serif">Even the OCIO engine with a LUT node would make as many transformation as needed for advance user. You might want to make things simple for most of the user, which is totally fine. But there is even great use to convert in the middle of your process to some different Color space (for keying or color grading for instance). </font></div>
<div><font face="'trebuchet ms', sans-serif">Its more complex that just interpreting the input and the output, it can have so many uses, and like Troy said it already exists and Xavier have a proof of concept if I'm not mistaking. </font></div>
<div><font face="'trebuchet ms', sans-serif"><br></font></div><div><font face="'trebuchet ms', sans-serif">I feel this is like the endless story :p </font></div><div><font face="'trebuchet ms', sans-serif"><br>
</font></div><div><font face="'trebuchet ms', sans-serif"><br></font></div><div><font face="'trebuchet ms', sans-serif">F.</font></div><div><font face="'trebuchet ms', sans-serif"><br></font></div>
<div><div><div><br><div class="gmail_quote">2012/4/9 Troy Sobotka <span dir="ltr"><<a href="mailto:troy.sobotka@gmail.com">troy.sobotka@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>Lengthy post. Apologies.</p><div class="im">
<p>On Apr 9, 2012 1:59 AM, "Peter Schlaile" <<a href="mailto:peter@schlaile.de" target="_blank">peter@</a><a href="mailto:peter@schlaile.de" target="_blank">schlaile.de</a>> wrote:</p>
<p>> okay, I wasn't very precise in my question.<br>
><br>
> So: why is it exactly a problem to keep the workspace always in Linear RGB<br>
> granted, that we have a float precision pipeline that doesn't clip?</p>
</div><p>Andrew said it best - the linear float is the model, not the space. There is linearization, where said values fit on a linear ratio scale (again, linearization only asserts ratios, not value positions), and finally chromacities.</p>
<p>Red is not red. Green is not green. And blue is not blue.</p>
<p>How each value relates is tied to the color space.</p><div class="im">
<p>> Or: what is the exact reason to use a different workspace color profile?<br>
> (besides nodes that clip values (which they shouldn't IMHO) and speed<br>
> reasons if for example input is YUV, transformations can be done in<br>
> YUV and output is YUV).</p>
</div><p>Simply, all color and perception is relative. A proper space defines not only "hardware" based reference points, but also viewing conditions.</p>
<p>YCbCr (YUV is a misnomer as it specifically is analog) would be a good example of a model without a space. Within YCbCr there is rec709, rec60, 240m etc. Each of those have _different_ transfer characteristics.</p>
<p>In plain terms, the Cb and Cr describe different intentions within each space.</p><div class="im">
<p>> In a second step, we can make the whole pipeline color management aware, but<br>
> that is really a lot of work. And: I still can't see the benefit over<br>
> a truely float *and* HDR aware RGB pipeline.</p>
</div><p>It would only be "a lot of work" if a library were not available, complete with interaction of over a decade of color data.</p>
<p>We already at times define a color space in Blender. For example, all inputs from JPG, TIFF, etc., use the linearization of sRGB. The chromacities are unaccounted for.</p>
<p>To highlight the fact that RGB values are more codes in the modern era, I would suggest looking at a sample image with an adjusted gamut.</p>
<p><a href="http://www.gballard.net/psd/go_live_page_profile/Browser_Color_Test_.jpg" target="_blank">http://www.gballard.net/psd/go_live_page_profile/Browser_Color_Test_.jpg</a></p>
<p>Again, until one knows a source space and a destination space, no transforms can take place.</p>
<p>So defining a working space is nothing more than defining the destination. For output, it defines the source. </p>
<p>We could of course create a custom Blender space and create hundreds of LUTs to convert to and from known spaces.</p>
<p>Or we could simply rely on the vast body of LUTs and ICCs already out there and leverage a library.</p>
<p>Remember, Blender is already defining color spaces at times, albeit in an inconsistent and incomplete manner.</p><div class="im">
<p>><br>
> Fun fact: the idea behind ACES looks like this: have the workspace *always*<br>
> nailed to ACES colorspace. To finally end this workspace colorspace craziness<br>
> and just work within the one and only workspace called ACES.<br>
> In fact, the same thing, Blender already did. With a RGB float space,<br>
> that shouldn't clip.</p>
</div><p>Again, RGB is not a space. It is a model. The limits lie in the space itself, which at times is sRGB.</p><div class="im">
<p>><br>
> So: other direction could be: let's nail blender to ACES color space and<br>
> everything is fine :) Or just keep it the way it is, but do that properly.</p>
</div><p>There is _no_ proper without defining a destination space.</p>
<p>This should leave no confusion. It cannot be done.</p><div class="im">
<p>Ton said:<br>
> For the rest of it, I have the impression it's all being made too complicated. Let's try to stick to design ideas for an efficient workflow for Blender, which is for 3d artists (who are not color experts) specifically. I am sure we can keep it nice simple, and still satisfy strict color quality demands :)</p>
</div><p>At the core is a very simple discussion. Source space. Destination space.</p>
<p>The simplest way to make this clear is to state, beyond a shadow of a doubt, that no one has any clue what they are looking at without color management. Full stop.</p>
<p>I would hope that this statement is relevant to any artist, 3D or otherwise.</p>
<p>With utmost respect,<br>
TJS<br>
</p>
<br>_______________________________________________<br>
Bf-vfx mailing list<br>
<a href="mailto:Bf-vfx@blender.org">Bf-vfx@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-vfx" target="_blank">http://lists.blender.org/mailman/listinfo/bf-vfx</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>____________________<br>François Tarlier<br><a href="http://www.francois-tarlier.com">www.francois-tarlier.com</a><br><a href="http://www.linkedin.com/in/francoistarlier">www.linkedin.com/in/francoistarlier</a><br>
</div></div></div>