Re: [Bf-committers] Blender developers meeting notes - 2018-10-22

[Troy Sobotka]

On Wed, Oct 24, 2018, 2:23 AM Brecht Van Lommel 
wrote:

> We've had this discussion before, and I still did not see the explanation
> from OCIO looks about looks being intended for this. The documentation
> seems to say something else.
>

You don't see it, yet it has been discussed with the lead developers and
many other OCIO folks ad nauseum.


This is a resolved point, and the documentation confirms the position.

> A “look” is a named color transform, intended to modify the look of an
image in a “creative” manner (as opposed to a colorspace definition which
tends to be technically/mathematically defined). An OCIO look typically
exists as a flexible addendum to a defined viewing transform.

But even besides that, it's just poor user interface design to use the Look
> setting for both artistic looks and saving to an intermediate file format.
>

That's Blender's design problem, not the design of the configuration. That
is something that needs to be redesigned within Blender.

I don't disagree, but that is the poor way that Blender integrates colour
management.

And when switching between Default and Filmic it's not good for None to
> have a a different purpose, settings should generally be orthogonal.
>

I don't believe this is asserted in OCIO. I can think of a number of
situations where this wouldn't be the case.

With that said, the Apple P3 branch works fine like this, and the various
contrasts behave identically under each display type.

T
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2018-10-22

[Troy Sobotka]

On Tue, Oct 23, 2018, 10:41 AM Brecht Van Lommel 
wrote:

> On Tue, Oct 23, 2018 at 7:25 PM Troy Sobotka 
> wrote:
>
> Does this refer to saving a render in log color space for loading into
> software that does not support OpenColorIO? I think it is using the Look
> feature for something it was not designed to do, to work around
> limitations.

The proper solution would be to allow saving images in a
> specified color space directly (Filmic Log in the current config?), without
> being affected by the display device or view transform.
>

I don't disagree that we need a file encoding transform stack, much like a
texture box has a stack of texture elements. The current implementation is
unworkable. Default could simply default to the current behaviour, with an
"Advanced" cascade panel that exposes the transforms.

All of that said, the design of the configuration is perfectly in line with
OCIO's design. The reference encoding is the Filmic Base Log, and the rest
are aesthetic twists on it. This has been confirmed multiple times via OCIO
folks. _It is using the Look precisely as it was designed_.

The Blender implementation of colour management should mature a little, but
sadly we are strained for developers. Short term, an OCIO node solves
99.95% of the issues. I'm reasonably certain that folks like Sebastian
would agree it is a crucial node to mitigate the Blender shortcomings in
the short term.

T
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2018-10-22

[Troy Sobotka]

On Tue, Oct 23, 2018, 9:53 AM Brecht Van Lommel 
wrote:

>
> I don't personally mind removing the old RRT and Film transforms for
> example, as Filmic provides a good replacement. But renaming e.g. "sRGB" to
> "sRGB Native 2.2" or "Filmic" to "Filmic Log Encoding Base" is in my
> opinion not an improvement, and certainly not worth breaking compatibility
> over. It also changes American to British spelling for example.
>

I'm fine with these sorts of changes in the bigger picture.

As we have discussed before, I also do not think we should require a look
> to be specified for the Filmic view transform to give correct results, the
> None look should work too.
>

None does work. It delivers a log base image, which is rather important for
plenty of folks, not the least of which was the BI's Agent.

Specifically, if the config defaults to a look on top of the log base, it
would be impossible to replicate what the actual BI did for Agent. That
seems odd, no?

None of these things are very difficult to fix, all I'm asking is if you
> want to contribute an improved configuration, please do it in a way that
> tries to preserve compatibility where reasonable and with an explanation of
> why the cases that break compatibility are acceptable.
>

I'm not resisting this. At all.

I'll push a branch that tries to maintain compatibility on naming.

T
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2018-10-22

[Troy Sobotka]

On Tue, Oct 23, 2018, 4:07 AM Brecht Van Lommel 
wrote:

> For a completely
> different config, we would need to provide some level of backwards
> compatibility and agree on the naming, I don't think there is time for
> that.
>

I was under the impression 2.8 was a clean break?

It strikes me as a horrible idea keeping something like the busted up RRT
and other crazy things in that config, doubly so that anyone can download
any configuration they want, or better, revert to an older version of
Blender?

The configuration really is a horrible mess and could be cleaned up in no
time.

With respect,
TJS

>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers meeting notes - 2018-10-22

[Troy Sobotka]

On Mon, Oct 22, 2018, 10:28 AM Brecht Van Lommel 
wrote:

> Here are the notes from today's developer meeting. Next meeting is Monday,
> 29 October 18:00 CEST (16:00 UTC).
>
> 1) Blender 2.8
>
> * Work continues towards the beta, an update on the current status will be
> posted on the code blog and presented at Blender Conference.
>

Can we put, even if we miss wide gamut, a full cleanup of the OCIO colour
config on the table?

Right now it is a horrible mess, and I think anyone familiar with it would
agree.

To this end, I've tried to add in the bare minimum for 2018, including
Apple P3 displays, to Filmic over at
https://github.com/sobotka/filmic-blender/tree/AppleP3?files=1

Having a streamlined config reduces complexity for the folks newer to the
subject, and encourages interaction as a result.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] 8th annual Open Source VFX Beers of a Feather at SIGGRAPH

[Troy Sobotka]

Forwarded message for SIGGRAPH attendees.

-- Forwarded message -

8th annual Open Source VFX Beers of a Feather

Monday, 13 Aug 2018, 6-8pm
Steamworks Brewpub, 375 Water St, Vancouver, BC  http://steamworks.com/

For those of you attending SIGGRAPH 2018 in Vancouver, we will once again
hold an event for developers and users of VFX-specific open source
projects.  It's a great chance to meet in person with people you've been
working with on the other end of the mail, while enjoying drinks and hors
d'oeuvres, courtesy of our generous sponsors:

Academy of Motion Picture Arts & Sciences (ACES and OSS)
Autodesk
DigitalFish, Inc.
DreamWorks Animation
Google Cloud
Industrial Light & Magic
Method Studios
Netflix
Peregrine Labs
Pixar Animation Studios
Sony Pictures Imageworks
Walt Disney Animation Studios
Weta Digital
Zorroa

Please direct questions to: lg AT imageworks.com

Please feel free to forward this email to your developers and post on the
appropriate mail lists for open source VFX projects you administer
or participate in.

Also, if your organization is not one of the sponsors but you'd like to be
(no contribution is too small), contact LG and there's certainly time to
help charge up a bigger tab, or to make sure we know to check with you for
sponsorship next year.
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Code quest weekly meeting notes - 2018-04-13

[Troy Sobotka]

On Mon, Apr 16, 2018, 1:34 AM Dalai Felinto,  wrote:

>
> Graphic Design, layout and icons
> * Lekker [Dutch for delicious] Blender goals:
>  - Cleaner and less distracting.
>  - Direct manipulation as much as possible.
>  - Notifications.
>  - Status bar.
>  - Responsive UI.
>

I'll again point out that the UI passive elements such as icons and
coloured text will display incorrectly on every Apple product post late
2015, and requires colour managing.

This is a growing unfortunate facet as HDR / wide gamut displays are
distributed more widely.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Patch: OCIO Parse Colorspace From Filename

[Troy Sobotka]

On Mon, Dec 11, 2017, 8:22 AM Adriano Oliveira 
wrote:

> I think this is ok, but do not really address "the tedium of manual setting
> of color spaces". No one would change two clicks in a drop down menu by a
> lot of typing in texture names: "_sRGB", "_linear"...
>

It really _is_ a functional solution for _thousands_ of materials. A batch
file renaming tool can do this in about ten seconds.

That is why a "[ ] sRGB" or "[ ] gamma corrected" check box in Texture
> Image node is the ideal solution for the unnecessary drop down for only two
> color space in this context.
>

It is far from ideal and would botch plenty of folks. These options would
be a tremendous regression.

Instead of mangling up pipelines, it probably makes sense to use one that
is more well fitted and streamlined. The filename is one such path that is
trivial to utilize.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Patch: OCIO Parse Colorspace From Filename

[Troy Sobotka]

On Mon, Dec 11, 2017, 5:57 AM Sergey Sharybin  wrote:
> - Image loader sets color space (based on either image header or other
> assumptions)
> The higher level reader then might override the color space based on file
> name.

> If we allow such an automatic guess, it should be other way around. If the
> file knows it's color space, it should be trusted, as it is more trustful
> than a file name.

>
Ok. So if we do that, what is the best method to set the defaults? Each
filetype has the colourspace set to the default role.

Would the following order work?

 * Set the filetype default to Null.
 * Test the colorspace variable for a Blender file setting.
 * If Blender file remains unset, test for filename.
 * If it remains unset, set to default role.

Is there a means to differentiate between whether the colorspace variable
was set via default role or user based setting?

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Patch: OCIO Parse Colorspace From Filename

[Troy Sobotka]

Greets.

In response to the thread regarding the tedium of manual setting of colour
spaces,
I've created this patch that leverages OpenColorIO's
parseColorSpaceFromString
functionality.

With this patch, filenames such as rubber_srgb.png, treealbedo_linear.tiff,
facescan_acescg.tiff, etc. will all honour the colourspace if it is found
in the
given configuration.

https://developer.blender.org/differential/diff/9682/

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Cold Start Developer Help Needed!

[Troy Sobotka]

On Sun, Nov 19, 2017 at 10:39 AM OllyFunkster  wrote:

> There's also a bit of VSE discussion in a Slack channel run by Gleb
> Alexandrov, who has some sensible concerns and ideas about the VSE's
> colour handling, caching and the like. I haven't been able to dedicate
> the necessary time to get into developing in a while, but do dip my toe
> into the VSE code occasionally.
>

I think it was me you were referring to, and not the excellent Gleb A.

The concerns are pretty straightforwards:
1) Implement a half float reference space.
2) Implement proper colour transforms to and from reference.
3) Implement > 8 bit per pixel import for FFMPEG in conjunction with 1.

This essentially makes the VSE an offline / online system and potentially
takes it up to a 2017 implementation. Olly had a pretty darn clever test at
half float that seemed to work.

I've been ridiculously short on time, and also waiting on Eevee to settle
in so that any code can be reused here. I'm reasonably sure some of the API
work can be reused in the case of the display buffers.

Added you (Dominique) to the Slack. There hasn't been too much discussion
sadly due to lack of hands available for the VSE. I've tried to distill the
issues down into a wiki over at GitHub.
https://github.com/sobotka/Blender-NLE-NextGen/wiki/Blender-NLE-NextGen

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Wide Gamut 2.8 planning?

[Troy Sobotka]

Just checking in to see if wider gamut support is still on the map as a
potential goal for 2.8?

Current blocker: now, https://developer.blender.org/T46860

Lukas, do you have an updated patch that we can make this work and applied
to 2.8 trunk sooner rather than later?

In addition to the above, Cycles completely ignores colourspace transforms
on non EXR formats.

Wider gamut support would include:
 * Support for wide gamut rendering for targets such as HDR10, Dolby
Vision, native Apple P3 gamuts.
 * Native realtime wide gamut work within Eevee.
 * Alternate rendering aesthetic driven outputs as a byproduct of the basis
rendering primaries.

Etc.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Non-Standard sRGB OETF transform T51216

[Troy Sobotka]

On Mon, Apr 17, 2017, 1:29 PM Sergey Sharybin  wrote:

>
> It doesn't matter whether you inverse LUT at a runtime or a-prioti if
> interpolation is implemented properly.


The interpolation can't work terribly well, even with large tables. The
DolbyPQ​ is a good example. Too much compression in a range of nonlinear.

The same applies for 3D LUTs where you need a shaper to achieve a uniform
perceptual range.


> This is not related on the inverse or direct sRGB transform, this issue
> will be visible with any 1D LUT (3D LUT i did not verify the clipping yet)
> on an extreme values.
>

Sean committed a patch that may address this. In theory, values beyond the
LUT should have been clamped to begin with. This could be another issue
rearing its head.

Any inverse lookup will be slower that the straight one.
>

See above. Doesn't work on many nonlinear LUTs.


> Using 4K points will be ~2x faster to find a point in LUT, but then you'll
> still be doing some interpolation.


> So i would suggest just to fix damn interpolation in OCIO.


It is a lookup search on the inverse, which delivers more accurate values
in heavily nonlinear curves. This is why most of the DolbyPQ transforms are
provided as nonlinear to linear, and the inverse is a lookup +
interpolation, as opposed to a lookup and interpolation on extremely dense
values.

Speaking of unnecessary: this is fully unnecessary to bake transform which
> has simple definition with formula into a LUT. Such a baking just gives you
> hedaache with dynamic ranges without giving any speedup.
>

Except as you can see, the definition of "sRGB" varies pipeline to pipeline
as in this particular instance. And let's not even begin to dive into the
myriad of variations on 2017 era transforms.

There is an ExpressionTransform in the pipeline that will hopefully get
committed soon...

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Non-Standard sRGB OETF transform T51216

[Troy Sobotka]

On Mon, Apr 17, 2017, 11:09 AM Sergey Sharybin  wrote:

>
> Guess you're talking about issue reported in [1]. The root of the issue
> there is coming from OCIO itself, which has numerical stability issue
> in lookupLinear_1D (and it's SSE variant) when index is far above the
> possible LUT index.
>

I think the inverse lookup is going to be subject to quite a bit of
numerical degrading. You would need a shaper likely to properly resolve the
values.

Does the performance suffer with a 4096 LUT on the inverse Sergs? The 65k
LUT, in addition to having unnecessary / unused ranges for the older SPI
pipeline, is on the gargantuan side.

With respect,
TJS

>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Non-Standard sRGB OETF transform T51216

[Troy Sobotka]

Whoops... wasn't T51216, but rather
https://git.blender.org/gitweb/gitweb.cgi/blender.git/commit/6fb874369c31649de7232235b0114344bfdb8e92

Anyways, the values and ranges are off and it breaks HDRIs.

With respect,
TJS

On Fri, Apr 14, 2017 at 3:53 PM Troy Sobotka <troy.sobo...@gmail.com> wrote:

> Any reason that the nonstandard sRGB OETF transform was expanded to
> include an "inverted" LUT as well?
>
> Why wasn't OCIO's native inversion sufficient? Why is the inverse building
> upon the nonstandard SPI based sRGB transform versus a proper 0.0 to 1.0
> sRGB OETF?
>
> With respect,
> TJS
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Non-Standard sRGB OETF transform T51216

[Troy Sobotka]

Any reason that the nonstandard sRGB OETF transform was expanded to include
an "inverted" LUT as well?

Why wasn't OCIO's native inversion sufficient? Why is the inverse building
upon the nonstandard SPI based sRGB transform versus a proper 0.0 to 1.0
sRGB OETF?

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Colour Pickers and Apple P3 Filmic Update

[Troy Sobotka]

Greetings all.

I'm hoping that there are a few people out there with Apple P3 displays.
This would include all 2016 MacBook Pros, as well as the 2015 iMac P3
models, and likely any Apple desktop devices released this year and onward.

The reference space in Blender is currently set to use BT.709 / sRGB based
primaries. That means that the colour of the lights are of three particular
and unique colours. For those that are aware of the Filmic transforms,
there is a new Apple P3 display variant that is designed to test the
default sRGB EOTF output.

An interesting side note regarding the Blender UI, that I think Campbell or
the Grumpy Russian might be able to answer...

It seems when I change to the new Filmic Apple P3 display, that the colour
picker for setting RGB albedo values becomes constricted. This is
surprising and rather extraordinary at the same time. I believe that the
pickers use the View transform selected, and I think this constricting
behaviour is due to the pickers preventing of negative values? This would
happen when someone attempts to select a value that is within the Apple P3
gamut, but beyond the BT.709 / sRGB gamut.

Is this a correct deduction?

More information:
https://github.com/sobotka/filmic-blender/issues/9#issuecomment-286014087
Filmic Development Branch:
https://github.com/sobotka/filmic-blender/tree/development

Thanks everyone for their eyes and testing...
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] External effects for VSE and or compositor nodes

[Troy Sobotka]

The VSE will be complicated developing effects under its current
architecture. The problem is that the VSE is designed for output from
Blender's 3D rendering largely, and that means that the values are scene
referred. Most formulas for effects and such currently out in the wild are
display referred, which means they won't work terribly well on scene
referred renderings.

With respect,
TJS

On Sun, Mar 12, 2017 at 9:00 PM Gaspar Fernández 
wrote:

> Hi all!
>
> There are only a few effects in Blender for VSE or compositor. I've been
> thinking about that for years. Even I found, in the past Blender used a
> C api to allow external effect plugins
> (
> https://wiki.blender.org/index.php/Doc:2.4/Manual/Sequencer/Effects/Plugins
> ).
> And don't know why this feature isn't supported now.
>
> Looking for a solution I tried to make my Blender build run image
> filters via Python API but it's very slow (2 frames/sec for a very very
> easy effect, inverting red and blue channels and alpha to 50%), also I
> did not tested using a Python lib so Python will be just calling my C
> lib which does the effect. But I think it may be better making them
> directly in C or C++, I've tested doing the same simple effect in C and
> it's realtime.
>
> I also thought about using a pluggable library for doing this (just
> effects on images or videos), like MLT, where we can add a lot of
> effects and image generators (another very very interesting feature for
> me). It's really difficult to render a strip, apply one effect with
> another program and import the new footage with effect, and sometimes
> animating effect properties or doing little changes is awful repeating
> the whole process again.
>
> What do you think about that?
>
> I've been playing with MLT source, if you think this is interesting I
> think I could make a POC integrating one effect into VSE to see how it
> behaves.
>
> Best regards,
> 
>
> Gaspar Fernández
>
> Facebook de Gaspar Fernández    Twitter
> de Gaspar Fernández  LinkedIn de Gaspar
> Fernández    Youtube
> de Gaspar Fernández 
> Google+ de Gaspar Fernández
> 
>
>
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] VSE devs?

[Troy Sobotka]

There has been very little VSE chit chat of late.

For folks interested in the VSE, where it is at, and where it might be
plausible to go with as little grafting as possible, there are a few wiki
pages in the following link. Perhaps with the new viewport, and in
particular, a speedy half float API, something might come of it.

https://github.com/sobotka/Blender-NLE-NextGen/wiki/Blender-NLE-NextGen

With respect,
TJS

On Wed, Mar 1, 2017, 1:55 AM OllyFunkster  wrote:

Also, sorry about my email header name being daft. I don't really call
myself "blender, blender" in real life. Sorted now!

--
Olly
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developers weekly meeting, 2017-01-22

[Troy Sobotka]

Apologies for the delay in response here. Extremely busy on my end...

On Sun, Jan 22, 2017 at 9:13 AM Ton Roosendaal <t...@blender.org> wrote:

- Filmic Blender has not officially been submitted for review, we'll ask
Troy Sobotka about it.
It's in github though: https://github.com/sobotka/filmic-blender
Main issue seems to be that the filmic OCIO files break compatibility.


There are several issues at play here, not the least of which is that
everyone should come to a conclusion as to how to move forward with the
default configuration.

First, the default configuration fails ociocheck:

ERROR: NOT DEFINED (default)
ERROR: NOT DEFINED (data)
ERROR: NOT DEFINED (compositing_log)
ERROR: NOT DEFINED (color_timing)
ERROR: NOT DEFINED (matte_paint)

In particular, the "data" role, among others, should be leveraged via the
API to avoid hard coded problems and yield an agnostic application from the
colour front.

Second, on the subject of backwards compatibility, it seems to be a
hobgoblin of certain mindsets, especially that the considerations for
backwards compatibility end up being somewhat arbitrary and whimsical. In
particular, the default configuration, in addition to failing ociocheck, is
a large stumbling block to moving forward in 2017 for a number of reasons.
It was a byproduct of duplicated / erroneous / inappropriate transforms,
some of which belong in discrete sets from Sony, ACES, and the Nuke default
configuration. These were never intended to be mixed and matched, but alas,
history is history and all we can do is attempt to move ahead...

How to move forward is a reasonable question here. Two cents from someone
that probably should be ignored:

   - Order "Displays" based on primaries of the display. That is, looking
   forward, REC.709 lights (aka the lights that the sRGB specification) would
   form one display grouping, with REC.2020 lights forming another cluster,
   etc. This would allow Blender to move forward with proper views to support
   Apple P3 displays, HDR10, etc.
   - Properly implement the data role and others. Remove the hard coded
   values "Default" etc. and instead implement roles, permitting any valid
   OCIO configuration to be properly loaded by Blender with no tweaking. Props
   to angavrilov for spotting the data space issue in Blender.
   - Remove the Sequencer role and switch it instead to one of the defaults.
   - Repair and remove the vast bulk of the unfortunate transforms that
   include the incorrect RRT and others.
   - Figure out what to do with the rather broken Instagram "emulation"
   modes (Hint: Garbage them). These aren't derived properly and essentially
   are random dice. Worse, when tacking on properly designed Look transforms,
   the complexity of integration with the many existing Instagram filters is a
   mess, and certainly would not work properly with Apple P3 or REC.2020 for
   example. In the Instagram Looks place, include a single custom transform
   skeleton for imagers to craft their own CDL transforms as required.
   - Implement Lukas Stockner's patch for colour space agnostic RGB.
   <https://developer.blender.org/T46860> This would permit Blender to
   properly render REC.2020 / HDR10, and other wider gamut spaces correctly.
   - Implement the proper sRGB EOTF as opposed to the Sony transform which
   has a confused range particular to Sony's pipeline. This would essentially
   be a noop, but clean up the values.
   - Permit EXRs to be subject to transforms. This is problematic as it
   currently exists given that you can't properly transform EXRs to various
   destinations.

As we can see, there are going to be a number of challenges cleaning up the
Blender configuration. I'm happy to do the work of designing the
configuration with Views, as well as even an alternate directory full of
typical camera transforms for ingestion. That said, we should probably
seriously consider getting the infrastructure in place properly before we
move forward.

Would this break compatibility of some older files? Yes. Is this an issue?
Not given that the entire source tree is available and the project is open
source. Would this surgery be more well suited for 2.8? Probably if we can
get discussions going in earnest.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proposal: Add scale operation to the Pixelate Node

[Troy Sobotka]

The coupling of nodes hard coded is perhaps one of the most destructive
paths for Blender.

Instead, perhaps effort should be put into providing a means to import and
export node trees and groups as singular nodes?

The greenscreen coupled up node from hell is an example of a worst case,
and it would be a shame to see this ill trend continue any further instead
of tackling the issue at the core.

With respect,
TJS

On Sun, Jun 5, 2016 at 5:55 PM Aaron Carlisle 
wrote:

> Currently, the Pixelate Node [1] is difficult for new users to know how to
> use because
> they do not know that they need to add a scale node before it inorder to
> get desired results.
> To easily fix this I purpose that a scale operator is added to the node
> making it easier to use.
>
>
> - Aaron Carlisle
>
>
> 1. https://www.blender.org/manual/compositing/types/filter/pixelate.html
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender VSE exported video goes from 1440p to 1080p

[Troy Sobotka]

Your issue has to do with encoding. Blender has very rudimentary support
for encoding, but nothing that could be considered robust.

I offered you a pretty decent entry point to a potential solution. The
output you have demonstrates that the encoded file is of the resolution you
set.

While I am no developer, I can say that your issue appears well out of
scope with regard to Blender's encoding issues, but rather an issue with
YouTube and its ability to properly detect the established parameters.
Perhaps try a YouTube support channel?

> And you guys wonder why more people do not use blender
>

I assure you that the men and women that frequent this list are not
wondering this.

At all.

TJS

>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender VSE exported video goes from 1440p to 1080p

[Troy Sobotka]

This isn't really relevant to this forum.

Go put a bounty on it at SE. I suspect it isn't getting tagged correctly in
the encode. Remember BINAE: Blender Is Not An Encoder.

“[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f1724bf0880]Protocol name not provided,
cannot determine if input is local or a network protocol, buffers and
access patterns cannot be configured optimally without knowing the protocol”

With respect,
TJS

On Sun, May 8, 2016, 7:39 PM blubee blubeeme  wrote:

> Bump this question. Anyone have any idea why?
>
> On Sat, May 7, 2016, 22:14 blubee blubeeme  wrote:
>
> > I was away from my computer for a while. Opening the video with mplayer
> > this is the output from the unedited video:
> >
> >
> 
> > Playing 2594x1458.mkv.
> > libavformat version 56.40.101 (external)
> > libavformat file format detected.
> > [lavf] stream 0: video (h264), -vid 0
> > VIDEO:  [H264]  2594x1458  0bpp  120.000 fps0.0 kbps ( 0.0 kbyte/s)
> > Clip info:
> >  ENCODER: Lavf56.40.101
> > Load subtitles in ./
> >
> ==
> > Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
> > libavcodec version 56.60.100 (external)
> > Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
> >
> ==
> > Audio: no sound
> > Starting playback...
> > Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
> > VO: [vdpau] 2594x1458 => 2594x1458 Planar YV12
> > V:   2.0   0/  0 23%  8%  0.0% 0 0
> >
> > opening it with vlc and looking at the codec information:
> >
> >
> 
> > http://i.imgur.com/m1wn3r4.png
> > http://i.imgur.com/UZE9zZr.png
> >
> > this is the video information for the blender edited file
> >
> >
> 
> >
> > Playing 2594x1458 exported from blender.mp4.
> > libavformat version 56.40.101 (external)
> > libavformat file format detected.
> > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f1724bf0880]Protocol name not provided,
> > cannot determine if input is local or a network protocol, buffers and
> > access patterns cannot be configured optimally without knowing the
> protocol
> > [lavf] stream 0: video (h264), -vid 0
> > VIDEO:  [H264]  2594x1458  24bpp  120.000 fps  6904.4 kbps (842.8
> kbyte/s)
> > Clip info:
> >  major_brand: isom
> >  minor_version: 512
> >  compatible_brands: isomiso2avc1mp41
> >  encoder: Lavf56.40.101
> > Load subtitles in ./
> >
> ==
> > Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
> > libavcodec version 56.60.100 (external)
> > Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
> >
> ==
> > Audio: no sound
> > Starting playback...
> > Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
> > VO: [vdpau] 2594x1458 => 2594x1458 Planar YV12
> > V:   1.4   0/  0 72% 25%  0.0% 0 0
> >
> > vlc information
> >
> >
> 
> > http://i.imgur.com/XKwdWCH.png
> > no metadata
> >
> >
> >
> > On Sat, May 7, 2016 at 12:59 PM, David McSween <3pointe...@gmail.com>
> > wrote:
> >
> >> So what do the properties of the second clip say when ipen in a media
> >> viewer?
> >>
> >> D
> >> On 7 May 2016 2:42 pm, "blubee blubeeme"  wrote:
> >>
> >> > That's correct, the first one was shot with ffmpeg and directly
> >> uploaded to
> >> > YouTube and it has 1440p available.
> >> >
> >> > The second one was edited in blender vse just to remove a few frames,
> >> > exported and uploaded to YouTube.
> >> >
> >> > The question is, why doesn't the second video have the 1440p option?
> >> >
> >> > It's the same video, the second one was just edited in blender.
> >> >
> >> > On Sat, May 7, 2016, 12:35 David McSween <3pointe...@gmail.com>
> wrote:
> >> >
> >> > > Well I just looked at the first one and it DOES say 1440 is
> available
> >> ;-)
> >> > >
> >> > > On Sat, May 7, 2016 at 2:25 PM, blubee blubeeme <
> gurenc...@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > That just might be the case that youtube didn't encode the video
> at
> >> > that
> >> > > > resolution yet but maybe not.
> >> > > >
> >> > > > I made these two videos the other day
> >> > > > This one directly uploaded after recording with ffmpeg:
> >> > > > https://www.youtube.com/watch?v=2NzSlo3knbk
> >> > > > This one I edited with blender then uploaded:
> >> > > > 

Re: [Bf-committers] Big Blender User!!

[Troy Sobotka]

On Sat, Apr 16, 2016, 2:43 PM Doeke Wartena  wrote:

> Correct me if i'm wrong.
> RGB = 256*256*256 = 16,777,216
> CMYK = 100*100*100*100 = 100,000,000
>

Wrong.

Full value RGB depends on the colour space chosen. In your case I suspect
you mean sRGB, at which point full value will equate to an absolute colour
value of 0.3127 x and 0.3290 y in xyY.

What is that colour in your printing context? We don't know! We don't know
the implied contexts of the ink colours, the paper absorption with the
various levels of ink, the illuminant, nor how you wish "white" to appear.

In the end, it is a fool's errand and an incorrect approach.

> That is correct only for 8-bit channels, that is 32 bits per pixel. That
is why saving to EXR is highly beneficial because you can save 16 or even
32 bits per channel.

It has absolutely _nothing_ to do with bit range.

With respect,
TJS

>
___
Bf-committers mailing list
Bf-committers@blender.org
https://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Big Blender User!!

[Troy Sobotka]

There is no such thing as “CMYK” any more than “RGB” is.

In the same way that RGB defines three uniquely coloured lights for each of
red, green, and blue, so too does CMYK define a unique ink for cyan,
magenta, yellow, and black. In addition to this, you have to factor in the
colour of the paper, the ink response to paper, and light source.

Given the above, there is no single method to convert to CMYK, and anyone
that tells you so is an idiot.

There _is_ a method to properly do so has been around for a while; ICCs.

If you would like to take something from Blender to print, there is only
one advisable method to do so (assuming you are using the default
configuration):

1) Tag / Attach an sRGB v2 profile to your rendered output.
2) Use another tool to convert and prepare your image for print using the
proper ICC profile of your chosen printer. This considers the ink colours,
total area coverage of the printer (TAC), black point compensation (BPC),
etc. All of this will be in the ICC profile of your printer.

Typically these days, for non professional printing, the print houses will
simply require you to ship your image in RGB with the colour space
information attached, which step (1) above would do. Preparing a document
ready for professional grade printing / rasterizing would require going a
step further and using the tagged image in a tool such as Scribus or
InDesign.

TL;DR: There is no way to properly prepare an RGB image for print properly
from within software without leveraging proper and unique ICCs for each
printing context. Though beyond Blender's scope proper, it is painless with
a little knowledge and an external tool.

With respect,
TJS

On Sat, Apr 16, 2016, 10:06 AM Knapp  wrote:

> Perhaps you can open it in Krita and save as PS format? I know that Krita
> can read PS format files but I am not sure about saving them. In any case
> you might want to just switch to Krita.
>
> On Sat, Apr 16, 2016 at 2:11 PM, Jens Verwiebe 
> wrote:
>
> > Hmm
> >
> > I darkly remember i added one day psd format ( to oiio ? ) on mac ?
> > Or was it only import or i muddled somemething cause it was long time
> ago ?
> > Dalai was envolved too, so perhaps ask him if he remebers.
> >
> > Jens
> >
> >
> > Am 16.04.2016 um 10:45 schrieb Siva:
> > > Hi Stephen
> > >
> > > As far as I know
> > > not only blender, renders from any 3d Software is going to suffer the
> > same fate, when it comes to CMYK printing
> > > there is no software which renders to CMYK
> > >
> > > renders are very similar to photographs, they are stored internally in
> > RGB and are not designed for CMYK
> > >
> > > like Bastien rightly said, exr would preserver all the data and hence
> > might ease your conversion process.
> > >
> > > Your printing people might be able to help you in easy and right
> > conversion process.
> > >
> > > and an addon to convert psd is again going to give you a PSD file in
> RGB
> > colorspace not CMYK. So technically there is not going to be any
> difference
> > >
> > > this is one of the articles about the topic
> > > http://forums.cgsociety.org/showthread.php?t=58907
> > >
> > > regards
> > > Sivaprasad Velayudhan
> > > Director - Operations
> > > Mob: +91 99400 14644
> > > Mail: s...@realworks.in
> > >
> > > Realworks Studios India Pvt Ltd.,
> > > 7/1, V.S.K. Building, Thondamuthur Road, Vadavalli
> > > Coimbatore - 641041
> > > Tamil Nadu
> > > India.
> > >
> > > - Original Message -
> > >
> > > From: "Bastien Montagne" 
> > > To: bf-committers@blender.org
> > > Sent: Saturday, April 16, 2016 1:10:05 PM
> > > Subject: Re: [Bf-committers] Big Blender User!!
> > >
> > > I’d have expected EXR to be the format of choice here (assuming - and
> > > hoping - photoshop does open that format, either natively or through
> > > plugins)? Being an HDR floating point format, it should allow for any
> > > kind of color conversion with (nearly) no loss of quality. And it can
> > > store several render passes separately, which can also be quite useful
> > > in post-process afaik…
> > >
> > > Le 16/04/2016 08:49, David McSween a écrit :
> > >> Perhaps cmyk conversion is hard but I wonder if you could apply a lut
> > via
> > >> color managment before saving?
> > >> On 16 Apr 2016 4:06 pm, "Stephen Keeling" 
> > wrote:
> > >>
> > >>> My name is Stephen and I use Blender every day for personal use and
> > >>> business. I love Blender's open interface and customization that is
> > >>> available. The one thing I really am hoping to see every day is an
> add
> > on
> > >>> or system update that supports exporting or saving my blend file into
> > a PSD
> > >>> instead of tiff or jpg or png. Adding a Photoshop add on or system
> > update
> > >>> would be extremely helpful For my business, I normally need to
> > convert
> > >>> every project into CMYK for print and that is where the colors of the
> > RGB
> > >>> jpg are really 

Re: [Bf-committers] release notes

[Troy Sobotka]

Can we at least have someone, anyone, as has been brought up and suggested
a fix was "coming" for God knows how long, implement a godforsaken mobile
view on the wiki?

Seriously. Like today. Tomorrow. It is a theme right?

Right now the wiki is absolutely unusable as the right side zooms in as the
left side fills the screen.

With respect,
TJS

On Sat, Feb 27, 2016, 4:10 PM Aaron Carlisle  wrote:

> And there should never be. This was apart of the wiki that lead to its
> destruction and to the manuals destruction.
> And I think many other developer will agree with me. Anyway lets not let
> this get started into a Wiki argument.
>
> On Sat, Feb 27, 2016 at 2:58 PM, Thomas Dinges  wrote:
>
> > Ah I see what you mean. Well there is simply no 2.7 category in the wiki
> > yet.
> >
> > Am 27.02.2016 um 20:57 schrieb Thomas Dinges:
> > > Can you be more precise please? ;)
> > >
> > > http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.77 I don't
> see
> > > anything pointing to 2.6 here.
> > >
> > > Am 27.02.2016 um 20:53 schrieb Knapp:
> > >> Why are the 2.77 release notes under 2.6 heading?
> > >>
> > > ___
> > > 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
> >
> ___
> 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] Updating Colour Configurations

[Troy Sobotka]

> On Wed, Nov 11, 2015 at 1:23 PM, Sergey Sharybin 
wrote:

> > What's the benefits comparing to use wider RGB
> > space? IMO, custom linear space in kernel will only cause problems --
more
> > tedious workflow in node trees, textures, lighting setup, impossibility
to
> > fake spectrum rendering, plus afair reasonable amount of BSDFs are
> > evaluated against RGB.

All of the above is regarding changing the gamuts for any tristimlus space,
_not_ changing the model / encoding scheme.

The issue is that because the basis vectors of any RGB / XYZ transform are
non orthogonal, _each_ RGB space behaves differently during rendering /
image manipulation. That is, the reference space you choose ends up
influencing the qualia of your renders / manipulations in terms of how
things look, making the choice of reference spaces an important one.

In all cases though, the reference remains tristimulus RGB of a given white
point.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Updating Colour Configurations

[Troy Sobotka]

On Nov 10, 2015 2:47 PM, "Brecht Van Lommel" 
wrote:
>
> I doubt GPU rendering is a problem, but I have no idea what the word
> "role" means in this context and what "implementing an XYZ role"
> means.

A role is simply a known alias that software can hunt for via OCIO. So for
example, if you have to convert colour temperature via a Bradford etc.
transform and require the space's XYZ primaries and white point, you could
request the “XYZ” role. It is provided for grabbing “Grading” or “UI”
transforms etc.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Updating Colour Configurations

[Troy Sobotka]

Greets Brecht.

On Nov 8, 2015 4:00 AM, "Brecht Van Lommel" 
wrote:
> > 2) To add in the proper transforms for the default iMac P3 displays.
>
> If this is just adding the P3 color space for reading images and
> display that seems reasonable. If it's more then please explain what
> that is.

It isn't. It would mean an output view transform.

The new P3 displays aren't P3, but close. It would be an output transform
probably labeled under a vendor family for something like “iMac P3.”

> > 3) To revisit the idea that we should be colour managing the entire UI,
as
> > icons and other bits now will look odder.
>
> I think it's inevitable if you want to display wide gamut images while
> still displaying the rest of the UI correctly. It's a huge task and
> needs a good design though, since it's easy to make a mess if it's not
> done properly, it affects a lot of code.
>
> > 4) Revisit the hard coded Cycles sRGB muckery and focus on fixing it.
>
> I think everyone agrees that this needs to be improved.
>
> Are you volunteering to actually implement 3) and 4), or just update
> the configuration for 1) and 2)?

Campbell is probably the most well equipped for (3), but it overlaps into
some of the mainstream UI elements such as color pickers and color ramps,
so it would be something to discuss.

I have only peeked at the Cycles GPU path code, but it doesn't seem like
there is a terrible level of chromaticity based hacks in place? I only saw
the sRGB transfer curve hard coded? Perhaps there is a bit in the SSS code?
(Being code that makes assumptions about the RGB primaries and rolls them
through XYZ such as the hard-coded color temperature node.)

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Updating Colour Configurations

[Troy Sobotka]

On Sun, Nov 8, 2015 at 5:17 PM Brecht Van Lommel <brechtvanlom...@pandora.be>
wrote:

> On Sun, Nov 8, 2015 at 6:42 PM, Troy Sobotka <troy.sobo...@gmail.com>
> wrote:
> > I have only peeked at the Cycles GPU path code, but it doesn't seem like
> > there is a terrible level of chromaticity based hacks in place? I only
> saw
> > the sRGB transfer curve hard coded? Perhaps there is a bit in the SSS
> code?
> > (Being code that makes assumptions about the RGB primaries and rolls them
> > through XYZ such as the hard-coded color temperature node.)
>
> Cycles inputs and outputs are mostly scene linear colors and it
> doesn't need to know much about that color space, but there are a
> couple exceptions.
>
> The simple changes would be in the wavelength, blackbody and sky
> texture nodes, which make some assumptions about using Rec.709 scene
> linear. An extra transformation between different scene linear spaces
> should be enough to solve that. The Blender API just needs to expose
> information about the scene linear color space so that Cycles can
> construct those transformations, which I guess are just 3x3 matrices.
>
>
I chatted with Antony at length on this and I am reasonably sure that there
is a quick and easy method to solve many of the issues in Blender while we
wait for OCIO to implement chromaticity information, which is hopefully
sooner rather than later.

The basic solution is to implement an XYZ role. This is reasonably simple
to carve out, and smaller studios / artists with unique configurations
would simply have to take care to provide the XYZ role and assert that the
white points are aligned.

The colour selectors and such could also leverage this role.

Do you think it is feasible to leverage the role against Cycles for these
sorts of cases or does the GPU path provide a problem?

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Updating Colour Configurations

[Troy Sobotka]

Greetings. There are few things I'd like to re-table after some rather
heated discussions in the past.

This mail is triggered largely by the fact that a large consumer vendor has
now integrated DCI-P3 displays into their entry level computers.

This would mean that Blender's default configurations will fail miserably
on them.

I'm willing to repair the configurations, assuming we can agree on the
following:

1) To remove the ACES configurations. They are old, hacked, and going to
mislead people via the name "ACES" to imply that they are canonized
versions.
2) To add in the proper transforms for the default iMac P3 displays.
3) To revisit the idea that we should be colour managing the entire UI, as
icons and other bits now will look odder.
4) Revisit the hard coded Cycles sRGB muckery and focus on fixing it.

Thoughts?
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] VSE render times really huge!

[Troy Sobotka]

It is also worth noting that some encoding schemas will see a degradation
in quality when encoding across threads.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] what is the difference between these 2 LINEAR operations? or a bug?

[Troy Sobotka]

On Apr 12, 2015 6:25 AM, Kévin Dietrich kevin.dietr...@mailoo.org wrote:

 where linear_burn is defined as: x + y - 1, and linear_dodge: x + y
 so that gives:
 x + 2y - 1, if (y  0.5)
 x + 2y - 1, otherwise

 I personally
 would remove it from Blender and Cycles altogether.

I would only add that for all blend modes, there should be a toggle for
display referred versus scene referred blending.

The above two functions for example, break horribly on scene referred
imagery such as output from Cycles as there is no unity point as there is
in display referred imaging; all values extend from zero to infinity.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Grading (WAS: Vignette node)

[Troy Sobotka]

On Mar 7, 2015 5:29 AM, Xavier Thomas xavier.thomas.1...@gmail.com
wrote:

 What do you mean by no scopes in the compositor?

 I don't consider the scopes of the sequencer nice, I consider them
horrible
 and horribly slow; they really should be ported to openGL and reuse the
 code of the image scopes.

The scopes via UV are great, and I too wish the the Viewer were somehow
more central to viewing. Perhaps that fits in with Mr. Wilkin's and
Mr. Riakiotakis' work?

We have a relatively minor issue in that the scopes assume a hard coded
color space. I have a proposal to integrate an XYZ role to alleviate this,
but I have to get it written up and submitted to Sergey. Hopefully then we
can update the scopes to work against arbitrary reference spaces.

 I agree that the compositor is not the best place to do grading and I
think
 the sequencer would be better.

I would suggest that the VSE is sub-optimal on a number of fronts if
considered alone, with some significant potential upside. Of note:

A) The VSE was designed for realtime playback. As such, most of the VSE's
work has legacy low quality 8 bpc code paths.
B) Contemporary grading suites all leverage nodal compositing due to the
complexity of grades.

So in terms of a grading design, I might suggest:
A) Rework the VSE to use a fully “offline” system. That is, leverage the
shot based nature to streamline proxy work for the editing, blocking,
timing, and preview portion.
B) Rework the VSE to provide a conforming / grading / finishing “online”
mode that works with a compositor view. Likely another compositor mode that
allows the full 32 bit algorithms to work for the highest quality output.

Some elements that would need further fleshing out, but it would at least
appear to be the foundation for a decent system without significantly
altering the overarching existing design for Blender. An additional
compositor mode and some VSE glue.

The only stumbling block would be the need for the VSE's curves to accept
OCIO transforms. For example, if an artist draws a linear diagonal curve
for a transform, if the artist is working in a display referred space, the
diagonal line can be assumed to be a nonlinear representation. To get a
proper dissolve / fade / over, it would need to be inverted via the OCIO
transform and the composite would be performed on linearized data at
whatever the reference primaries are.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Vignette node for Blender's Compositor

[Troy Sobotka]

Multiplication isn't exactly complex.

With respect,
TJS

On Thu, Mar 5, 2015, 5:25 AM Johnny Matthews johnny.matth...@gmail.com
wrote:

 True, but is it out of the question that some of the node groups could have
 efficiencies added by coding them more atomically?

 On Thu, Mar 5, 2015 at 7:07 AM Kévin Dietrich kevin.dietr...@mailoo.org
 wrote:

 
 
  Le 2015-03-05 14:00, Johnny Matthews a écrit :
 
   David, I'm not sure your tone here is helpful.
  
   Also to take a stab at where would the devs stop? Take a look at
   http://www.redgiant.com/products/magic-bullet-looks/ [1]
 
  That would be the equivalent to having a node groups library, which a
  vignette effect can be part of. This is something that a lot of users
  have been doing for a long time.
 
 
  Links:
  --
  [1] http://www.redgiant.com/products/magic-bullet-looks/
  ___
  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

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Vignette node for Blender's Compositor

[Troy Sobotka]

On Mar 5, 2015 6:13 AM, Johnny Matthews johnny.matth...@gmail.com wrote:

 Oh you burned me so bad there.

It wasn't intended as a burn, and I regret that you saw it as such.

The idea that a multiplication isn't complex was directed at the suggestion
that there would be “efficiencies” if coded at a more “atomic” level; a
node that merely performs a multiplication would not see such gains.

I am also curious why you discredited Mr. McSween's line of reasoning
above? If one examines industry leading tools such as Nuke, one will not
find a multiplication blur vignette node.

While this might seem a curious omission in an industrial imaging
application, we can wonder if the vignette node:
A) Does the node model the dispersion and chromatic aberration
characteristics of a lens near the periphery?
B) Does the node, when dealing with A above, manage variable primary
reference spaces correctly?
C) Does the node offer compression adaption for anamorphic or other
non-spherical lens representations?
D) Does the node offer variable density of the light occlusion?
E) Does the node adapt to the variable distortions of a lens model?

Most of these facets are unique and complex, and as such, would likely be
modeled into a more granular set of nodes, which would be welcome I am
certain. The nuances of each of these would require an understanding of
optics to model correctly, and designed to some of the standards already
relevant for a visual effects workflow.

Hopefully the depth of your knowledge can cover some of the above issues
and a more granular set of nodes is plausible.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Luminance patches

[Troy Sobotka]

Thanks all for the comments. I thought I'd post what I just posted via IRC
to here.

As a general summation, the larger issue here is tackling the fact that any
RGB manipulation transform must route through OCIO. If a single point
doesn't, it breaks the whole pipeline.

Of course, artistically it is also great to have the proper luminance
values for a given color space of course, as it makes matting, black and
white conversions, alpha manipulations, and many other things much more
accurate.

On Tue Feb 17 2015 at 14:24:51 Campbell Barton ideasma...@gmail.com wrote:

 Though I'd draw the line at removing them altogether as D1082
 proposes, since not all colors in Blender go via our image/render
 pipeline. (we have code dealing with on-screen colors, themes etc).


As we can see from the general sprawl of code reuse and duplication of
incorrect weights etc. (specifically regarding luminance here) we can see
that we can't insulate ourselves from having a developer use the functions
in an incorrect fashion. I'd cite the incorrect weights in Freestyle and
GLSL as a case in point; we actually have _more_ color problems since the
introduction of OCIO than we did prior now due to legacy functions.

Further, even when the elements are for a user interface function, they
probably should be color managed. In addition to the rather glaring fact
that not all displays are sRGB, and many are wide gamut, we also have the
problem that within the realm of UI we have a need for color management.

The color wheels (HSV) come to mind. If the developer uses the rgb_to_bw
function, they just broke their entire color chain. Now the developer
shouldn't use the rgb_to_bw function, but how should they know that?

Finally, the function implemented perfectly implements the existing
functions, with no added complexity to the developer, nor additional
overhead. It is literally a unified and cohesive 1:1 version. Oh, and it is
a small baby step to have Blender's color management near completion.

So:
1) Not all outputs go to a platonic sRGB display (as no such display
exists), and in fact as is likely in many smaller studios, most are wider
gamut (Eizos at the BI, no?). RGB is a relative color model.
2) There would need to be a division and added complexity separating
artistic GUI elements and non-artistic, for no reason other than to add a
level of complexity and the potential for the entire color management chain
breakage.
3) There is no added overhead with a proper OCIO luminance function.
4) There is no added function complexity with the proper OCIO luminance
function.
5) There is no way to prevent a developer from accidentally implementing a
broken function and breaking the entire color management chain.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proposal: 2D handler for Compositor

[Troy Sobotka]

On Fri, Jul 25, 2014 at 10:12 AM, Sam Vila samv...@gmail.com wrote:
 After seeing the new sunbeams node I just notice that it would be VERY
 handy to have a node in the compositor to display a handler that you can
 move around the screen and provide coordinates to be plugged into other
 nodes.

That handle is canvas aware editing, and that is in the works
currently. No small task by any feat, and likely means that one view
will become the reference point as it does with every other compositor
out there.

Typically, the moment you select an active node in most compositors,
the viewer will switch to that node as input for interaction, and the
adjustments can be made in a given active viewer. It just happens that
Blender's viewer has evolved somewhat from an historical point, and
the holistic approach was not possible.

I do like the idea of using a gripper as a driver however, but that
might be another subject.

 Another inconsistency I notice is the fact that after you enter in the
 compositor editor you need to click on the checkbox: Use nodes to start
 using the nodes, this is very silly design cause if you don't click that
 option you cannot use any meny in that editor or do anything so basically
 you're FORCED to check that box to start using the tool, it might be
 something trivial but it doesn't have any sense to have that option and
 click on it, it's 100% redundant and things like this makes more difficult
 for new users to adapt into blender.

This has recently been discussed quite a bit on this list.

As with all things around Blender, I find it useful to believe in the
folks that have coded it and realize that there is likely a reason
that the things are the way they are. Sometimes it is historical
legacy code that can take ages to rewrite, or sometimes it is another
issue.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] 3d LUT in Blender

[Troy Sobotka]

On Jun 15, 2014 7:52 AM, Adriano Oliveira adriano.u...@gmail.com wrote:

 Where and how?

Via OpenColorIO's configuration.

Feel free to contact me off-list directly if you need assistance.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] 3d LUT in Blender

[Troy Sobotka]

On Jun 14, 2014 7:01 AM, Adriano Oliveira adriano.u...@gmail.com wrote:

 Is there suport for 3d LUT in Blender?

Yes.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Luminance Coefficients

[Troy Sobotka]

While looking through Blender's code, I noticed that there were legacy hard
coded values for luminance.

These are hard coded values based on the sRGB and 709 primaries, as opposed
to the particular color spaces a given OCIO configuration may have. This
would lead to incorrect derivation of luminance if the reference space is
not sRGB / 709.

I decided to patch Blender to use the reference space coefficients listed
in the OCIO configuration file, which is relatively straightforward.

The coefficients are summoned per pixel, which would mean having a global
structure useful to reference them, but I don't see a relevant place to
store them.

It would seem logical to store them on configuration loading, reloading,
and potentially if a set coefficients call is made.

Where and how does it make sense to store these values in Blender's
architecture?

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Colour Managment

[Troy Sobotka]

On Apr 20, 2014 8:28 AM, Tom Wilshaw tom.wils...@btinternet.com wrote:

 I see what you mean now about the colour wheel. Is there a projected time
for fixing this issue?

https://developer.blender.org/T39707

 The issue is that with scene referred data it is deadly tricky to
calculate
 the out of gamut values. 

 Could you elaborate on this? Is it because sRGB or REC.709 assumes things
are normalised?

If you down gamut a scene referred (0..infinity) image to sRGB / 709
primaries from a wider gamut, it isn't terribly easy to spot the out of
gamut channels on the positive side without checking the transformed RGB
values against max() and 0.

My suggestion of normalizing the values is nothing more than an easier way
to spot them; anything less than zero or greater than one.

 So is XYZ. If you look at ACES primaries sources dumped raw to sRGB,
it looks equally wonk.

 It does, but code values are still rather more intuitive in ACES by
virtue of it being RGB based. For example, a mid grey card, an inportant
reference in visual effects, should read 0.18, 0.18, 0.18 in ACES. In XYZ,
it reads 0.1715, 0.1800, 0.1816.

0.18 is a convention of course, and any RGB set could theoretically align
in XYZ as you described (Warning: Guess math alert!) by normalizing your
RGB white point to xy 0.33 0.33 via a Bradford.

In a scene referred image of course, many grey cards may land at random
value levels depending on whatever convention you implement. Value 103.1 is
equally valid.

Again, a single exposure data value of 0.18 for a grey card is a pure
convention.

 A move to XYZ would fulfill our own needs well enough for working with
the cameras that we do, however it doesn't seem like the best long term
decision for Blender itself. ACES is an open standard which is set to
become increasingly common. Blender might do better to be ahead of this
trend, rather than effect a move to XYZ only to have to move to ACES at a
later date in order to satisfy users in these fields.

The issue is that ACES _currently_ does not easily fulfill the broad range
of needs.

Deviating from the specification would effectively negate the upside of the
standard.

All we can do is wait until either ACES evolves further. Until that time,
in my estimation, it is a sub-optimal decision.

XYZ on the other hand, is going nowhere and is a universal standard as
well, so _if_ there is a debate about internal representations, it is not
entirely without merit. It is perhaps the first de facto open standard in
color.

 Do you think it would be worth trying to gather the opinions of other
users who use Blender for visual effects or postproduction (or even
animation)? We might start a Blender Artists thread and see what a few
other people think? Many artists don't follow the mailing list.

My experience is that the color theory discussions on BA have resulted in
underwhelming participation.

Color still confuses the heck out of folks, and can be an intimidating
topic.

It certainly is for me.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Colour Managment

[Troy Sobotka]

On Apr 7, 2014 9:09 AM, Tom Wilshaw tom.wils...@btinternet.com wrote:

 We
 think that, from a technical viewpoint, XYZ would be an excellent
solution. The
 main problem we see is that, with the exception of Y, it is not intuitive
to
 artists. A small adjustment to the Z channel just doesn't convey the
same
 sort of readily interpretable information that one gets in RGB. We
suppose the
 tools could work in RGB, but process in XYZ, but this will add extra
processing
 and complexity, along with a (perhaps insignificant) performance change.

This would only apply to your working space. It is entirely realistic to
make your color picker the primaries of your wide gamut display etc.

OCIO provides aliases that handle all of this quite readily.

Sadly, Blender's color wheel / square is not color managed yet, and as
such, it dumps pure display referred values to the output. This effectively
prevents an artist from selecting colors properly.

 Our
 current approach is to:
 1. Linearise
 (we got a 1D LUT from DNG EXIF tag, it just needed scaling).
 2. Matrix
 convert, without any clipping.

 ACES RICD). A precisely calibrated light source is also used. In our case,
 tungsten lighting and tungsten white balance. We used published data for
the
 Macbeth chart sRGB code values. The results of applying the linearization
and
 matrix on input through our OCIO config, and then using sRGB and RRT on
output
 gives a very similar appearance to the camera manufacturer's 3D LUT for
 conversion to REC.709. There are some small issues due to experimental
error,
 which we are working on.

There is a much easier method. Leverage Argyll to recognize the IT8 and
generate a matrix, then use the resultant matrix as an OCIO transform. ;)

 As
 you can see, none of this is clipped, but it can provide processing
problems.

The issue is that with scene referred data it is deadly tricky to calculate
the out of gamut values.

Hence why I suggested a simple scale to a known value (1.0) and scaling
back. While at the 1.0 scaled values, anything beyond 1.0 or negative is
out of gamut, and can be noted.

Note this obviously only applies to a down gamut. An up gamut with wider
primaries will likely hold the smaller gamut.

 None of these numbers would need to be negative if ACES, or XYZ, were
used.
 When we render with the RRT all of these values get gamut mapped in in a
very
 pleasing way.

Exactly.

 Why
 couldn't Blender use the ACES primaries, but keep the current options of
 default and RRT output?

Because to the best of my knowledge, the ACES standardization is intended
to achieve just that, and is intended to be accepted in whole.

The above approach you outlined is precisely what ToS did I believe. That
said, it doesn't quite qualify as ACES, and at that point, XYZ may work
more ideally.

 Another
 approach would be to incorporate an LMT for sRGB material, but I agree
that
 this would probably cause more problems than it solved.

Exactly.

 I
 know that using only the primaries from ACES would be a deviation from the
 spec, but Blender could incorporate the ACES spec so that those who want
to use
 ACES can do so fully, whilst also allowing deviations for those who want
a more
 traditional video style workflow. What problems would this cause?

Likely none, but again, using XYZ is equally viable, with the upside that
many matrices are readily available for XYZ.

 The
 issue is that there are still some critical areas that are not color
 managed, such as the color picker / wheel. Having the picker broken
affects
 even sRGB of course, but is much more obvious in wider gamuts.

 Hopefully the picker / wheel and remaining pieces will be addressed in
the
 near future.
 Personally
 this has never given me major problems, as a lot of colour work is done
by eye
 or with the scopes, so the adjustments are subjective and relative. I
don't
 know enough about the internal workings of these tools to really comment.

You have to fully understand what I am communicating to appreciate the
issue. Crappy sRGB display? That is what you see. Wide gamut Eizo? You see
wide gamut primaries. DCI-P3 projector? That is what you see.

In this sense, there is a huge discontinuity with what you see and your
internal data. There is no way to select colors correctly.

 However, if Blender was to move to a wider gamut, would this need to be
done
 before setting up colour management for the colour wheel?

Exactly.

 ACES
 by default would cause legacy problems here. XYZ however, would not.
 Again,
 would it be possible to use the ACES space, and then clip out of gamut or
high
 dynamic range stuff for sRGB or REC.709 outputs if people select
default?

This is precisely what I was suggesting via XYZ; it would be entirely
invisible, unless someone opened up an EXR saved natively, and even then,
it is very likely any post house would be easily able to interpret it.
Perhaps even easier than sRGB / 709 primaries because XYZ (and ACES) are so
wide that it 

Re: [Bf-committers] Colour Managment

[Troy Sobotka]

On Apr 7, 2014 9:09 AM, Tom Wilshaw tom.wils...@btinternet.com wrote:

 We
 think that, from a technical viewpoint, XYZ would be an excellent
solution. The
 main problem we see is that, with the exception of Y, it is not intuitive
to
 artists. A small adjustment to the Z channel just doesn't convey the
same
 sort of readily interpretable information that one gets in RGB. We
suppose the
 tools could work in RGB, but process in XYZ, but this will add extra
processing
 and complexity, along with a (perhaps insignificant) performance change.

This would only apply to your working space. It is entirely realistic to
make your color picker the primaries of your wide gamut display etc.

OCIO provides aliases that handle all of this quite readily.

Sadly, Blender's color wheel / square is not color managed yet, and as
such, it dumps pure display referred values to the output. This effectively
prevents an artist from selecting colors properly.

 Our
 current approach is to:
 1. Linearise
 (we got a 1D LUT from DNG EXIF tag, it just needed scaling).
 2. Matrix
 convert, without any clipping.

 ACES RICD). A precisely calibrated light source is also used. In our case,

 tungsten lighting and tungsten white balance. We used published data for
the
 Macbeth chart sRGB code values. The results of applying the linearization
and
 matrix on input through our OCIO config, and then using sRGB and RRT on
output
 gives a very similar appearance to the camera manufacturer's 3D LUT for
 conversion to REC.709. There are some small issues due to experimental
error,
 which we are working on.

There is a much easier method. Leverage Argyll to recognize the IT8 and
generate a matrix, then use the resultant matrix as an OCIO transform. ;)

 As
 you can see, none of this is clipped, but it can provide processing
problems.

The issue is that with scene referred data it is deadly tricky to calculate
the out of gamut values.

Hence why I suggested a simple scale to a known value (1.0) and scaling
back. While at the 1.0 scaled values, anything beyond 1.0 or negative is
out of gamut, and can be noted.

Note this obviously only applies to a down gamut. An up gamut with wider
primaries will likely hold the smaller gamut.

 None of these numbers would need to be negative if ACES, or XYZ, were
used.
 When we render with the RRT all of these values get gamut mapped in in a
very
 pleasing way.

Exactly.

 Why
 couldn't Blender use the ACES primaries, but keep the current options of
 default and RRT output?

Because to the best of my knowledge, the ACES standardization is intended
to achieve just that, and is intended to be accepted in whole.

The above approach you outlined is precisely what ToS did I believe. That
said, it doesn't quite qualify as ACES, and at that point, XYZ may work
more ideally.

 Another
 approach would be to incorporate an LMT for sRGB material, but I agree
that
 this would probably cause more problems than it solved.

Exactly.

 I
 know that using only the primaries from ACES would be a deviation from the
 spec, but Blender could incorporate the ACES spec so that those who want
to use
 ACES can do so fully, whilst also allowing deviations for those who want
a more
 traditional video style workflow. What problems would this cause?

Likely none, but again, using XYZ is equally viable, with the upside that
many matrices are readily available for XYZ.

 The
 issue is that there are still some critical areas that are not color
 managed, such as the color picker / wheel. Having the picker broken
affects
 even sRGB of course, but is much more obvious in wider gamuts.

 Hopefully the picker / wheel and remaining pieces will be addressed in
the
 near future.
 Personally
 this has never given me major problems, as a lot of colour work is done
by eye
 or with the scopes, so the adjustments are subjective and relative. I
don't
 know enough about the internal workings of these tools to really comment.

You have to fully understand what I am communicating to appreciate the
issue. Crappy sRGB display? That is what you see. Wide gamut Eizo? You see
wide the particular wide gamut primaries for that display. DCI-P3
projector? That is what you see.

In this sense, there is a huge discontinuity with what you see and your
internal data. There is no way to select colors correctly.

 However, if Blender was to move to a wider gamut, would this need to be
done
 before setting up colour management for the colour wheel?

Exactly.

 ACES
 by default would cause legacy problems here. XYZ however, would not.
 Again,
 would it be possible to use the ACES space, and then clip out of gamut or
high
 dynamic range stuff for sRGB or REC.709 outputs if people select
default?

This is precisely what I was suggesting via XYZ; it would be entirely
invisible, unless someone opened up an EXR saved natively, and even then,
it is very likely any post house would be easily able to interpret it.
Perhaps even easier than sRGB / 709 primaries because XYZ 

Re: [Bf-committers] Gooseberry and UHD Rec.2020

[Troy Sobotka]

On Mar 23, 2014 3:12 AM, Ton Roosendaal t...@blender.org wrote:

 If something is broken it should just be fixed. Is this a report or issue
in our tracker? Is there a clear agreement on how to fix things?

I believe Antony is aware of the issue, and has a decent enough handle on
how deep down the rabbit hole it goes. If desired, this can be added to the
tracker.

 Or do you think this is many months of development time - and therefore a
mid/long term topic to solve via the film project?

I believe the color wheel is a relatively shorter term fix. Of course,
there are some legacy code paths that likely would require deeper
consideration.

The color picker needs would be:

A) Use an artist defined transform for transfer / tone curve properties.
Following Katana and the like, this accounts for the perceptual selection
needs (log or such versus a linearized data model).

B) Hook the picker color display into the pipeline to account for different
primaries. This permits wide gamut and alternate outputs to properly
display sRGB, as well as properly correct sRGB outputs.

Currently the picker dumps raw minimum to maximum values, and therefore it
always displays the color primaries of whatever the output device is.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Gooseberry and UHD Rec.2020

[Troy Sobotka]

Seeing as how we are hitting a compatibility breakage, I was wondering how
some of the remaining color issues might be tackled in preparation for
Gooseberry.

In particular:

1) Will Gooseberry target UHD and REC.2020? Has any consideration been
given to the color pipeline for the cross-studio boundaries etc?

2) Given the proliferation of 2020, should the remaining breaking points in
Blender be resolved for Gooseberry? In particular the color wheel being
broken and multi-head display would be worthy targets.

3) Would the BF be willing to see a cleanup of the OCIO config? Namely to
cleanup the sRGB transforms and make them primaries adjusted, as well as
clean up the legacy ACES elements for referencing the ToS content. In the
latter, perhaps making the transform clearer that they are not ACES
transforms, but rather customs etc?

Does anyone have any thoughts on this given the looming context of
Gooseberry?

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Updating OCIO luts in runtime

[Troy Sobotka]

On Jan 26, 2014 11:10 AM, tamerlan311 tamerlan...@gmail.com wrote:

 Apply LUT node currently has the following problems:
 2) Ignores that blender internally use linear color space, but LUT
profiles
 mainly required srgb.

This is incorrect.

LUTs do not require sRGB.

Further, there are many implications of color transforms that are
important, such as changing the color model of the data to pull a key or
secondary grade region, etc.

Remaining in a scene linear or display linear model has nothing to do with
the need for a color transform node. It is an artificial barrier, and an
OCIO node is an important and welcome addition.

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?

[Troy Sobotka]

On Jul 9, 2013 5:48 AM, François T. francoistarl...@gmail.com 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?

[Troy Sobotka]

On Jul 9, 2013 8:23 AM, François T. francoistarl...@gmail.com 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?

[Troy Sobotka]

On Jul 9, 2013 1:15 PM, Sergey Sharybin sergey@gmail.com 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?

[Troy Sobotka]

On Jul 7, 2013 11:50 PM, Sergey Sharybin sergey@gmail.com 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] Color management broken?

[Troy Sobotka]

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] Cineon/DPX speed up

[Troy Sobotka]

On Mar 12, 2013 10:36 PM, Sergey Sharybin sergey@gmail.com wrote:

 If the question is more about 'if we could use ocio instead of hardcoded
 conversions -- yes we could. If we shall -- no idea, depends on what's
 exactly going on there.

This.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Compositing output while editing

[Troy Sobotka]

Canal the backdrop.

TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Cineon/DPX speed up

[Troy Sobotka]

On Mar 12, 2013 3:27 PM, Julien Enche julien.en...@gmail.com wrote:

 1) At the moment, the IB_test flag is not taken in account in the
 imb_load_dpx_cineon function, so color conversion happens twice. I
 haven't really find out what should be done and what can be skipped when
 this flag is set. Can you give me more information on the purpose of
 this flag so that I could adapt the code to use it efficiently (and
safely).

Is there any way we can unbind the DPX code in such a way that it uses OCIO
and merely flags it as log etc? As I understood it, the DPX code makes
assumptions on the format and decodes accordingly?

I ask because it would permit loading of different styled logs (Josh Pines
versus Cineon etc.), color primaries, etc.

Curious if it is feasible to hand the log transfer curve conversion and
color primaries off to OCIO?

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Blur Node: Gamma audit - retire?

[Troy Sobotka]

I thought I'd crawl into the code for the Gamma toggle in the Blur
node now that we have a proper color management system in place.

CODE
float inputColor[4];
this-m_inputProgram-read(inputColor, x, y, sampler);
if (inputColor[3]  0.0f) {
inputColor[0] /= inputColor[3];
inputColor[1] /= inputColor[3];
inputColor[2] /= inputColor[3];
}

/* check for negative to avoid nan's */
output[0] = inputColor[0]  0.0f ? inputColor[0] * inputColor[0] : 0.0f;
output[1] = inputColor[1]  0.0f ? inputColor[1] * inputColor[1] : 0.0f;
output[2] = inputColor[2]  0.0f ? inputColor[2] * inputColor[2] : 0.0f;
output[3] = inputColor[3];

if (inputColor[3]  0.0f) {
output[0] *= inputColor[3];
output[1] *= inputColor[3];
output[2] *= inputColor[3];
}
/CODE

It strikes me that a few things are horribly incorrect here:

1) It appears as though that this node _always_ assumes that alpha is
associated, and pre-divides. This is most certainly not paying
attention to Sergey's recent alpha changes.
2) It appears that this node does a mere squaring of values, which is
problematic.
3) Gamma is erroneous, as it fails to address sRGB or 709 transfer
curves in an appropriate fashion, so the usefulness seems entirely
questionable.

To this end, I wonder if this toggle should be removed from the UI.
This would keep legacy files loading, and prevent artists from
mangling up their work inadvertently?

Thoughts?

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Adding image format in the VSE

[Troy Sobotka]

On Jan 27, 2013 6:24 PM, Campbell Barton ideasma...@gmail.com wrote:
 but Im
 not sure about demosaicing, if its just some automatic calculation on
 load -

It isn't. There is much more complexity that would also need to be
unchained from a raw image.

If we were to attempt and add a Variable Number of Gradients (VNG),
Patterned Pixel Grouping (PPG), or Adaptive Homogeneity-Directed (AHD)
interpolation approaches, they belong in a node and it likely suits
Blender's file loading more appropriately[1].

With respect,
TJS

[1] Otherwise it would turn into option hell in the image loading and
likely add overhead to the image buf.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Color Correction Node - Lift

[Troy Sobotka]

On Mon, Jan 14, 2013 at 7:21 AM, Bartek Skorupa (priv)
bartekskor...@bartekskorupa.com wrote:
 Conversion to sRBG inside the algorithm can be treated as one of the 
 operations this node performs.
 If we don't call this conversion to sRGB, but primary adjustment or 
 whatever else - we don't anymore perceive it as a bug, don't you think?

I'd be confident calling this a bug largely because any assumptions of
color space, including transfer curve as in this instance, will often
lead to unintended consequences. Again too, the notion that a
conversion to sRGB transfer curve happens likely means the node is
fundamentally problematic in a scene referred paradigm.

 If it's left this way we would only have to change names of the operations.
 Gain should be called Slope and Lift should be called offset.
 Then everybody who knows those terms simply don't get unexpected results.

Sure, the label might be improved, but Offset + Slope isn't likely handy.

There _is_ a correct gain as well as reference ASC CDL transforms
provided via OCIO, and perhaps we can more further integrate the API
into adjustments such as this example?

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Color Correction Node - Lift

[Troy Sobotka]

On Sun, Jan 13, 2013 at 3:57 PM, François T. francoistarl...@gmail.com wrote:
 but you have to know that Color Balance does a
 sRGB conversion internally. I don't think it would be good to do the same
 in CC

This is unfortunate. I suspect this should be reported as a bug now
that we have a proper color management system in place for transforms
and expose the transfer curve.

All nodes should make zero assumptions of the color space and transfer curves.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Color Correction Node - Lift

[Troy Sobotka]

On Jan 11, 2013 7:27 AM, Bartek Skorupa (priv) 
bartekskor...@bartekskorupa.com wrote:


 R = (1-C) * L + C

I don't believe this would work well at all with scene referred models /
spaces, of which Blender is.

Perhaps it is wiser to shift the default operation to ASC CDL format?

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Color Correction Node - Lift

[Troy Sobotka]

On Jan 11, 2013 10:31 AM, Bartek Skorupa (priv) 
bartekskor...@bartekskorupa.com wrote:

 I'd prefer it working like LIFT/GAMMA/GAIN does, but this is my personal
taste.

You missed my point.

The formula does not work on scene referred data.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Color pipeline todo: alpha

[Troy Sobotka]

On Thu, Dec 20, 2012 at 10:36 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
 Premul for float and key for byte images could work.

Just in the interest of consistency, if we are going with
Premultiplied naming convention, can we roll with the inverse of
Unpremultiplied and apply it consistently?

I checked in with Mr. Selan and he suggested that Unpremultiplied as
consistent. Mr. Gritz uses[1] the TIFF convention of Associated and
Unassociated convention.

I'm open to whatever naming convention we rest on, and only hope we
can apply it consistently throughout the interface. In particular, the
sidebar panels should likely list Premultiplied and the node
conversion should reference Premultiplied and Unpremultiplied.[2]

The Color Unpremultiply term should probably be re-evaluated to
avoid confusion, as it is an order of operations event, and the
current label is far to close to the other terms which can only amount
to greater confusion.

Blender needs to take whatever path is most healthy for it, but we can
at least aim to apply the terminology consistently.

With respect,
TJS

[1] 
http://lists.openimageio.org/pipermail/oiio-dev-openimageio.org/2011-April/004193.html
[2] http://comments.gmane.org/gmane.comp.lib.openimageio.devel/1406
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Color pipeline todo: alpha

[Troy Sobotka]

On Thu, Dec 20, 2012 at 11:52 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
 I like the names associated and unassociated because they don't
 describe how you arrived at the color, just the way it is stored.

Agree 110%. It also eliminates the rather erroneous assumption that
unassociated and associated alpha are purely as simple as a divide or
multiply away. A do-undo sequence on an associated alpha scene
referred image with 1.0 values would likely destroy the data without
some workarounds.

That still leaves our Color Unpremultiply order of events term a
little... awkward.

Needless to say, perhaps you or Sergey could agree upon and set the
baseline and then we can work to get the terms consistent throughout
the UI.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Color pipeline todo: alpha

[Troy Sobotka]

On Thu, Dec 20, 2012 at 1:21 PM, Bartek Skorupa (priv)
bartekskor...@bartekskorupa.com wrote:
  Straight and Premultiplied are the ones that most of the users know and 
 are used to.

We can agree that most is a speculation?

 Unpremultiply sounds to me like saying unpush instead of pull.

It might not be fantastic, it is a relatively standard term[1]. While
I'm not a fan of either the Premul or Unpremul, the advantage of the
un version is that they form a useful pair.

Nuke is as attached in the JPG.
Houdini offers both Multiply by alpha and Divide by alpha in their
Premultiply node.
Shake was manual IIRC.

With respect,
TJS

[1] See links in previous email.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] distance along line scalar - labda or lambda?

[Troy Sobotka]

 Campbell Barton:
 Theres an inconsistency I noticed yesterday maybe someone here knows
 whats going on...

While on this subject, I noticed a while back that there are a few
neareast typos littered throughout the code, where the author
clearly intended nearest referencing nearest neighbour or the
like. Unless we mean something relative to the our current GPS
coordinates. ;)

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Writing a Compositor node plugin?

[Troy Sobotka]

 Is there any chance that the registering the new nodes goes through some old
 system of nodes? I can now compile without any errors however(maybe
 naturally) my node does not show up in the nodes in Blender. So I am
 suspecting that I am not able to register this new node in the system
 properly.

I wrote a wiki page on a minimal node tutorial here:
http://wiki.blender.org/index.php/User:Sobotka/Misc/Minimal_Node_Tutorial

There is a minimal node-skeleton branch here:
https://github.com/sobotka/blender/tree/node-skeleton

Hope that helps someone a little...
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Regression: 50383 ATTN Sergey

[Troy Sobotka]

If you turn clipping off now on RGB curves, and change Max X to a 1.0
value, you can't slide the point past 1.0

50383 is the breakage point.

Looks like the following commit broke the clipping of curve windows:


r50383 | nazgul | 2012-09-04 05:40:47 -0700 (Tue, 04 Sep 2012) | 6 lines

Mango request: display sliders for current point in curve mapping

--
svn merge -r49893:49894 ^/branches/soc-2011-tomato
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Can BGE be relicensed?

[Troy Sobotka]

The topic of this thread comes up at least once per year. Please use
Google as there is a vast body of information gathered from
tremendously respectable parties, including key developer opinions and
insight.

Technical hurdles are an obvious issue. Mr. Barton cites the library
issue but also the practical contribution issue:

Heres a list of people you'd need to convince to change license
www.blender.org/development/credits[1]

Further, there is a concern over dynamics. It is impossible to cite
the reasons that any given developer or contributor contributes, and
therefore utterly impossible to predict the influence a licensing
change may have. Again, while not specifically addressing the Blender
Player, Mr. van Lommel's quote still bears reading:

Let's not paint this issue in black and white, LGPL for example also
means properietary software could take parts of Blender code and use
it. If Blender would have many proprietary plugins and modifications,
it does result in a different development dynamic.[2]

Finally, we have Ton, whose quote as of 2010:

Based on feedback from key developers, the likelyhood there's a
relicense to LGPL happing is near zero. Let's focus on ways to get
end-user level useful extensions possible.[3]

Above and beyond all of this, if we cite the beginning of the thread
and the premise that must be accepted to carry this thread on, from
Mr. Hassani:

This subject is about whether BGE can be and should be relicensed to
be more competitive as a game engine in the current environment we
find our self in.

The above thought is in fact seductive, but utterly, incomprehensibly,
and tragically a falsehood of ideology.

There is no need to be more competitive in a Libre / open source
project. Full stop. To contest this statement would require contesting
Blender's existence and evolution itself.

The evidence is overwhelming.

With respect, and with the dearest hope that this thread ends as it
does every year,
TJS

[1] http://comments.gmane.org/gmane.comp.video.blender.devel/28386
[2] http://www.mail-archive.com/bf-committers@blender.org/msg04384.html
[3] http://www.mail-archive.com/bf-committers@blender.org/msg04379.html
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Colormanagement Issue

[Troy Sobotka]

On Tue, Sep 25, 2012 at 5:47 AM, Brecht Van Lommel
brechtvanlom...@pandora.be wrote:
 I've changed the
 configuration file now to be a bit more clear and avoid this
 intermediate step, but it should have no influence on the end result.

Odd.

I SVN upped and the issue is gone now.

Nice work on cleaning up the OCIO config.

Thanks so much for whatever it was that fixed the issue.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Colormanagement Issue

[Troy Sobotka]

It appears that something internally is a little wonk in the color
management system.

When loading the OpenColorIO test images such as Marci.png, the
transforms do not yield a 1:1 sRGB transform.

I've tested using ExponentTransforms as well, and no matter what
config (including the Nuke default), the higher end of the values
appears off by quite a factor.

Nuke passes the test fine, so it extends beyond the default Blender
set of OCIO config files. Further, the sRGB transform uses the Sony 1D
LUT in conjunction with an ACES matrix, which seems entirely odd. In
theory, if the default internal Blender space is intended to be sRGB /
709 primaries, only an ExponentTransform or a 1D bounded 0..1 LUT
should suffice to linearize the sRGB asset. This is tangential to the
issue however.

The reference images can be found at the OpenColorIO site at
http://code.google.com/p/opencolorio/downloads/detail?name=ocio-images.1.0v4.tgz

The simplest test is to load the Marci PNG file from the Nuke set, and
compare against any image viewer.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Revisiting Color Curves

[Troy Sobotka]

Now that OCIO has begun to land in Blender, I thought it might be
worth evaluating whether we could improve the curves control in the
compositor a little.

Currently, curves operates on data between output referred values 0 and 1.

With native scene referred values, 1.0 is effectively meaningless.

Might it be possible to implement a method to display a region of the
data in the curves window by specifying a lower and upper limit?

Thoughts?

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Keys to control mask feather

[Troy Sobotka]

On Sun, Jul 22, 2012 at 9:50 AM, Campbell Barton ideasma...@gmail.com wrote:
 * shift click to drag out feather points can be kept (this means shift
 for subtle movement - realize this conflicts with shift for 1/10th
 motion).

Is it possible to negotiate this and keep the Blender-wide consistency
with Shift? I am all for breaking rules and consistency where the
situation dictates it, but I question if this is the case here.
Further, I can see the Shift 1/10th being useful to the feather as
well.

 Im not all that happy with mask allowing left mouse selection - as you
 say it gives conflicts with shift+select.
 IMHO we should remove that functionality but thats a bigger discussion.

+110%. Blender has a relatively (like it or not) universal consistency
with the right click to select. Breaking this internal consistency
here is likely sub optimal. Are there options here?

Anything we can do to make the pieces fit better together as a whole
within the established Blender paradigm would seem like a solid step
forward.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Blender Default LUTs

[Troy Sobotka]

In the interest of trying to get a decent starting point of LUTs
together, I thought I'd throw out the question as to what basic LUTs
should Blender support out of the default configuration?

We should probably consider the historical Blender legacy here and
provide a most minimal transition for Blender artists. With that goal
in mind, I propose that we keep Blender's internal color space as
close as possible to the existing conditions.

This shouldn't impact those that wish to extend Blender to other
pipelines, but rather keep the default configuration sane for those
that are migrating into color managed workflows.

I've loosely documented some thoughts at
http://wiki.blender.org/index.php/User:Sobotka/Color_Management/Blender_CM_Integration,
with the LUT section at
http://wiki.blender.org/index.php/User:Sobotka/Color_Management/Blender_CM_Integration#Proposed_LUTs.

Interested to hear any thoughts on the matter.

With respect,
TJS

PS: Within OCIO, it is obviously possible to achieve some LUT-like
effects without an actual LUT. The term is used merely to reduce the
terminology to something that an artist may see in the final Blender
interface.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Color to greyscale conversion - confusion

[Troy Sobotka]

On Jun 23, 2012 5:01 AM, Campbell Barton ideasma...@gmail.com wrote:


 - Texture and shading pipeline use rgb_to_bw() which treat RGB more
 evenly which might be better for shading when very un-even influences
 for RGB channels could be problematic for shading with textures of
 different colors (rgb_to_bw)

 - Where as with compositing - perceptual rgb-bw is much more
 important (rgb_to_grayscale)
g list

Technically this is in the domain of LUTs once OCIO lands.

The problem with attempting a non color aware approach is that it takes us
directly into the hard coded color domain again, as all values are assumed
1:1 linear sRGB.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Color to greyscale conversion - confusion

[Troy Sobotka]

On Jun 22, 2012 10:34 AM, Campbell Barton ideasma...@gmail.com wrote:

 Does anyone know why there are 2 different color - grey-scale
 conversions in blenders code?

 float rgb_to_bw(const float rgb[3])
 {
return 0.35f * rgb[0] + 0.45f * rgb[1] + 0.2f * rgb[2];
 }

 float rgb_to_grayscale(const float rgb[3])
 {
return 0.3f * rgb[0] + 0.58f * rgb[1] + 0.12f * rgb[2];
 }

 From reading the code its not clear why one of these are used over
another.

There is no singular method to achieve a conversion.

The second looks like an sRGB luminance model transformation.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Color to greyscale conversion - confusion

[Troy Sobotka]

On Jun 22, 2012 11:56 AM, CoDEmanX codemanx
codem...@gmx.de@codem...@gmx.de
gmx.de codem...@gmx.de wrote:
 but correct seems to be:

 Y = 0.2126 R + 0.7152 G + 0.0722 B

Again, there is no singular correct.

I believe the above is a luminance based conversion from linearized sRGB.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developer meeting notes, 17 june 2012

[Troy Sobotka]

On Sun, Jun 17, 2012 at 10:20 AM, Tobias Oelgarte
tobias.oelga...@googlemail.com wrote:
 Are there any plans to fix the various color management issues that
 exist for over a year now?

Proper color management via OCIO will alleviate many, if not all, of
the issues you have reported.

 Examples:
 * Any TextureNode in BI delivers the managed result, even if it is
 supposed to be a bump or normal map. It doesn't have an linear/color
 option like cycles does.

Dealt with via a defined raw data OCIO config role.

 * 8bit textures/images are treated differently as floating point
 textures in texture slots or inside the image editor

And let's not forget the Sequencer, which has a float representation
of sRGB gamma transfer.

How to deal with 8 bit per channel images is up in the air. Blender
core developers will need to deal with the lazy allocation system
concerns.

 * the image editor displays float images right at the moment, but the
 values written to the image are managed, giving wrong displacement.

Proper input asset colorspace management will deal with the above
issue you cite.

 (could also need a button to let the user decide the color space)

Much of this is dependent on which LUT package and OCIO configuration
is established. Granular controls for artist needs is a given in a
color managed system, and between Blender's integration and the
flexibility that OCIO provides, the concerns you have above should be
addressable.

A larger issue might be education.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Blender developer meeting notes, 17 june 2012

[Troy Sobotka]

On Jun 17, 2012 3:04 PM, Tobias Oelgarte tobias.oelga...@googlemail.com
wrote:

 One general issue that i have at the moment is that there is no clean
 line between images with color data and images which represent absolute
 data. Bumpmaps, Normalmaps, Alpha and Masks should be linear

In the short term, a little education on file formats would suffice.

Use EXR. EXR data is strictly assumed linear and is untouched in the
loading into float buffers.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Compositing - We are doing it wrong (partially)

[Troy Sobotka]

On May 14, 2012 4:37 AM, Tobias Oelgarte
tobias.oelgartetobias.oelga...@googlemail.com
@ 
tobias.oelga...@googlemail.comgooglemail.comtobias.oelga...@googlemail.com
wrote:
 This is partially wrong, since for masking you need sRGB values within
 the range of 0-1.

There are two assumptions here.

Alphas are strictly linear and should not be bound to any color space such
as sRGB.

The 0..1 clamp is required for both associated and unassociated alpha
compositing operation however.

Your point stands regarding the need to avoid linearization procedures.
There are currently three methods around this IIRC:

1) Use a proper linear file format that would avoid linearization. EXR.
2) Brecht provided a manual override to force a linear interpretation for
Cycles if memory serves for certain textures.
3) Saving into the correct alpha file channel in all formats will avoid the
sRGB linearization. Once inside Blender, that channel can be used as
desired.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Dilate/Erode node

[Troy Sobotka]

On May 6, 2012 5:43 AM, Jeroen Bakker j.bak...@atmind.nl wrote:

 I would like to know if the we should retain the old algorithm, only use
 the tiles algorithm, or make a selection between the two algorithms.

+1 for selecting algorithms akin to the Transform node.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Nodes auto hide sockets on collapsed nodes

[Troy Sobotka]

Accordion on pointer proximity?
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] On Format Woes

[Troy Sobotka]

On Thu, Apr 5, 2012 at 8:53 AM, Andrew Hunter and...@aehunter.net wrote:
 It was brought to my attention that Xavier Thomas has already working
 such an integration. Perhaps the developers could chime in on the
 possibility of getting this work merged to trunk.[2]

Further along this path, I just did a test using Sebastian's DPX
sample using OCIOConvert (from within OCIO). The result aligns nicely
with Blender's internal format and preserves highlights.

The command I used off of the base DPX was:

ocioconvert ~/Downloads/A007C025_120403.dpx slog ~/Desktop/sony-test.exr linear

I used the Nuke OCIO configuration as Nuke's internal (relatively non
HDR) linear config matches nicely against Blender's[1].

In visual tests using ociodisplay, the results look extremely promising.

Prior to using the ocioconvert function, it is necessary to establish
the environment variable OCIO, such as:

export OCIO=/path/to/config.ocio

I'll conduct further tests as I roll along here. For now, this would
be a deadly simple way to get an archival quality source (the DPX) and
post production pipeline ready files in EXR via a simple batch script.

If there is any interest in wanting further details, email away.

With respect,
TJS

[1] https://github.com/imageworks/OpenColorIO-Configs
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Mango development notes

[Troy Sobotka]

On Mar 15, 2012 11:54 AM, Tom M letter...@gmail.com wrote:
 Just emailed sergey some links on light reconstruction, but nothing
 jumped out as being great.

A typical HDRI approach is a well bracketed sphere map of the lighting from
the position of the CGI elements. Three stops up, one at exposure, and
three down, merged into a properly linearized HDR image.

Blender will obviously struggle at the merging procedure as we currently
don't have a mapped color space, only a linear model.

A rather useful thing might be to somehow generate a 3D reconstruction in
addition to the HDR, to correctly position lighting elements. This might
make it extremely useful for generating lighting positions and correct
falloff.

A Project from View onto this 3D lighting reconstruction would also
account for various interactive lighting elements such as intermittently
occluded lights, lighting cues, etc.

Are we currently able to use a Project from View' approach with an image
sequence?

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] kickstarter for VSE ?

[Troy Sobotka]

On Mar 12, 2012 11:18 AM, Pittsburgh Filmmakers Institute 
digi...@pghfilmmakers.org wrote:
 I was wondering if there would be any interest in having a kickstarter
project
 started for someone to work on Blender's VSE, taking most of the ideas
from
 places like http://wiki.blender.org/index.php/Dev:Ref/Requests/Sequencer

While a funding approach is fine on paper, there is probably a bit of
ground to cover prior to such an undertaking.

1) Backing of the BF. Mr. R is the leader of this ship and the core
committers would need buy-in prior to any such attempt or much of the work
would appear to be for naught.

2) What is the design pattern? Offline systems are geared towards more
advanced production and reflect an entirely different workflow to a wholly
online system. There are also challenges within both regarding design
decisions. If history is any indicator, a bit of research and wiki
documentation outlining the desired approach seems to be a better method to
move forward than a hasty move. The examples in the wiki are all over the
map in terms of overarching design goals, and in some instances run counter
to each other.

Two pennies from a worthless idiot. I am entirely in support of moving
components along, but I'd worry that without a concrete design plan with
rationale, we'd likely be no further along than where we currently are.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [44654] trunk/blender/source/blender/imbuf /intern/openexr/openexr_api.cpp: Fix for OpenEXR half float save function resulting in

[Troy Sobotka]

On Mar 5, 2012 1:32 PM, Campbell Barton ideasma...@gmail.com wrote:

 The reason support for saving non-linear Imbufs was added is because
 float sequencer buffers were not linear (internally AFAIK they are
 still not - this is needed for sequencer float blending which differs
 with linear buffers),

This is absolutely correct and brings up a questionable design decision
made long ago. The sRGB non linear floats in the VSE pose several issues
now:

1) Incorrect blending (alpha overs, disolves, fades, etc.)
2) Degradation. With the sRGB LUTs in place, I suspect any export from the
VSE will be crunched to 16bpc via the LUT.
3) Architectural anomaly. This puts the VSE as the sole violator of the
rect_float is linear mode.

My thinking is that we should rectify this soon and make the VSE linear
float and provide a lower grade 16 bit LUT for display performance.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] PATCH: Add Cubic B-Spline with Prefilter to Transform Node

[Troy Sobotka]

Greetings all.

I've finished writing a patch that adds cubic b-spline with prefilter
scaling to Sergey's most awesome Transform node.

I'd hope that everyone can appreciate the quality that it brings to
the table for the artists around Blender. It's a significantly
impressive algorithm that I'd hope can be considered for inclusion.

This patch was made possible thanks to the brilliant mind that
participated in the LibMv GSOC project, Matthias Fauconneau. His
extreme patience and question answering permitted this buffoon to
morph the code into Blender's compositor. Huge thanks to Sergey too
for his patience. ;)

WIKI PAGE INFORMATION:
http://wiki.blender.org/index.php/User:Sobotka/Cubic_B-Spline_Scaling_Algorithm

OFFICIAL TRACKER LINK:
http://projects.blender.org/tracker/index.php?func=detailaid=30411group_id=9atid=127

CODEREVIEW LINK:
http://codereview.appspot.com/5711050/

Matthias Faconneau's proof of principle:
https://gitorious.org/cubic-b-spline-interpolator

Further reading:
http://www.ipol.im/pub/algo/g_linear_methods_for_image_interpolation/

Thanks so much for your time,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Associated, Unassociated, Predivided Alpha Madness

[Troy Sobotka]

Thought I'd follow up the confusing discussions with a Wiki page.

http://wiki.blender.org/index.php/User:Sobotka/Associated_and_Unassociated_Alpha

With respect,
TJS

PS: Corrections and questions are not only welcome, but encouraged. If
you wish to keep it off list, feel completely free to email me
personally.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] libredcode

[Troy Sobotka]

The SDK is obviously not even a remote option as of the suffocating
distribution licensing.

The rest falls under reverse engineering which, in addition to being
prohibited legally as per their camera EULAs, would also be subject to a
firmware change at the source that could potentially destroy all effort.

On Feb 19, 2012 11:51 AM, f.paglia...@gmail.com wrote:
 Very interesting question!
 Looking forward to know more about choice on R3D files.

 In fact they're quite compressed and easy to use compared to EXR
converted from them!

There are a plethora of good reasons that the vast bulk of visual effects
pipelines work off of EXR which are far too numerous to list here. R3Dcode
would fail on many fronts even if it were not encumbered by restrictive
licensing and lack of specification.

If I were to wager, the official software will be used to generate the
offline proxies and then again to pull the EXRs for online.

Just a hunch. ;)

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Color Unpremultiply

[Troy Sobotka]

Matt Ebb wrote:
 Eh? I presume you're talking about the render option that does this at
 the end of the pipeline before saving imagery out of the
 renderer/compositor, and not the option per image that does this when
 loading the image, right?

My bad. It was the only place I could find that made as much sense
from a global perspective.

It _really_ belongs in the output panel. I suppose I should patch this. Erf.

 For situations where you're just rendering through BI straight to disk
 with no compositor, and the system knows it's Premul, you may have a
 point. But afaics that's not how this option works - it's a bit
 misleading having this option in the shading panel, which is full of
 BI related properties, since this is something that happens at the end
 of blender's entire imaging pipeline. If you want to make things
 clearer, perhaps the option should be on the compositor output node
 itself, and when you're not using the compositor, rendering straight
 out of BI, it could just do the right thing automatically since it has
 all the information to make that decision itself. Much of a muchness
 really, though...

Gespertino wrote:
 However, I still wonder if that checkbox doesn't belong to the compositing
node instead of the shading panel.

Yes. Yes. Yes. Completely agree. It's my fault!

I did _try_ to get the blasted thing on the output node, but the UI
goes fuzzy on some of those special nodes, of which the output is one.

If anyone wants to step up and demo how to put interface elements on
it, I'd love it.

Matt Ebb wrote:
 Well, the image viewer kind of 'implies' that output images should be
 premultiplied (otherwise they'll look bad), but this is probably also
 the fault of there being no option to choose how to interpret imagery
 that you're viewing, to correct accordingly.

I really would love to see the patch[1] for toggling associated versus
unassociated view committed to trunk on this note. I think it is poor
form to provide a default view that doesn't accurately depict the
internal alpha state, but alas...

With respect,
TJS

[1] 
http://projects.blender.org/tracker/?func=detailatid=127aid=28782group_id=9
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Color Unpremultiply

[Troy Sobotka]

I always feel like a low rent chess player speaking with a grandmaster when
I am speaking with Brecht, but I believe there is some inaccurate
information here.

So here goes...

On Feb 17, 2012 12:42 PM, Brecht Van Lommel brechtvanlom...@pandora.be
wrote:
 The problem is that it's not actually true that this is always the
 correct thing to do.
[...]
 If you're compositing over a black background, leaving this option off
 will give the exact correct result.

To the best of my knowledge, this statement is fundamentally incorrect.

In all non-linear associated alpha (premultiplied) formats, the RGB values
are in fact associating both emission / occlusion and a color component.

The net sum of this is that _all_ linearizations on assocaited alpha RGB
non-linear values are incorrect[1], irregardless of the background you
intend to perform the over upon. Why? Because the RGB values themselves,
directly out of the file, are exactly as explained above; a hybrid
associated combination of occlusion / emission and RGB color.

I will do my best to explain this in images if I can find some time today.

As to how to determine default behavior, it is not easy because we are
faced with both non-linear (EG: TIFF) and linear formats (EG: EXR) as well
as the combination of associated versus unassociated alpha. The inherent
nature of Blender's image loading code with correct flagging and
granularity is the issue.

With respect and hopefully not looking like a complete fool here,
TJS

[1] It should be considered more coincidence that 0.0 and 1.0 happen to be
identical in pre-linearization and post-linearization, rather than any
degree of overlapping logic.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] blender UI state

[Troy Sobotka]

While it is great to be discussing Blender's UI, I would hope that it
may be acceptable to put Mr. Roosendaal's recent comment on a request
at the top of the page:

Instead of explaining why you need it, or calling it better or
more useful, just write down a neutral and very precise
specification of how it looks.

As we can see from this brief thread, words like obvious, good,
better, etc. are without context and of relatively worthless value
with regards to Blender's UI discussion.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Tile Branch OCIO node

[Troy Sobotka]

Seeing as how we hit a stalemate with the potential of trying to get a
low level implementation of color management into Blender, I am hoping
that we can include Jeroen's massively useful OCIO node. It is already
written, worked wonderfully, and of tremendous value.

Perhaps we could consider this node temporary until we can tackle
colour management in earnest at a deeper level?

It would be extremely useful to many artists and greatly elevate
Blender's viability for some workflows.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] FFMPEG PRESETS: writeffmpeg.c 1253-1344 still needed?

[Troy Sobotka]

Campbell can probably answer this as I suspect the lines in question
are probably from pre 2.5x lineage.

Since we migrated the FFMPEG to a full RNA structure with presets in
the scripts folder, I was wondering if we still required lines
1253-1344 of writeffmpeg.c?

It appeared that the lines in question manually assigned the variables
in C, where it seems that the preset scripts now do that.

To test, I commented out the lines and the presets still work.

So is this code legacy cruft?

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Proposal for 8 bpc sRGB / 32 bpc linear float

[Troy Sobotka]

Not sure the last mail got through as I attached a JPG. I've also
bumped it to fix some rather glaring formatting boo boos I created.

Screenshot:
http://img259.imageshack.us/img259/9556/infosample.jpg

Patch:
http://projects.blender.org/tracker/index.php?func=detailaid=29754group_id=9atid=127

Summary:
1) Displays current reported bit depth.
 Either 8 bpc or 32 bpc depending on buffer present.
2) Displays reported color space.
 This reveals that our internal IB_PROFILE should probably be set
for 32 bit and 8 bit images that are created by pressing + in the UV
Image Editor. Currently they are set to IB_PROFILE_NONE which seems
incorrect. The 8bpc buffer should likely be IB_PROFILE_SRGB and the
32bpc option should likely be
IB_PROFILE_LINEAR_RGB.
3) Revealed a bug in the current system where, despite 8bpc content,
it always reports as a float value.
4) Added the disabled color code.
 Now the RGB appears as red, green, and blue text respectively. I
believe the newer text handling permitted this.
5) Unified the spacing on all of the elements.
 The element kerning should be consistent now.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] New Year's Alpha

[Troy Sobotka]

I thought I'd point out that as of r43004 both associated and
unassociated alpha can now be properly handled for non-linear formats
such as TIFF.

A tremendous thanks to Brecht for the fix.

The TL; DR for Blender artists:

When importing a non-linear associated alpha image, artists should
always check Color Unpremultiply from the image properties panel.
This will unassociate the alpha from the RGB values _prior_ to
linearization from the sRGB format.

When exporting to non-linear file formats with associated alpha,
artists should be certain to select Color Unpremultiply from the
Shading panel. This will unassociate the alpha from the RGB values
_prior_ to exporting from the linear internal format. The result is
then associated to the sRGB transformed pixels.

Don't hesitate with any questions.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Proposal for 8 bpc sRGB / 32 bpc linear float

[Troy Sobotka]

There seems to be quite a bit of confusion with regards to the two
different buffer formats in Blender and how they are handled
internally.

From an artist perspective, this is deadly complicated as if you are,
for example, painting in 8 bpc sRGB space, your overs are not linear
whereas in 32 bpc, they are.

I propose two simple changes within Blender that would help artists
understand where and how they are working with respect to the buffers:

1) A readout in the UV Image viewer that shows that a buffer is either
8 bpc sRGB, 32 bpc linear, or any other format. The grey area where
the RGB values and Alpha are displayed would be the most logical.

2) A check to force float. Currently via lazy allocation may leave the
values in 8 bpc sRGB for things such as painting. A checkbox (similar
to the VSE minus the confusing sRGB format) would force the float
buffer to be defined and cleared when not.

And most importantly, have a happy New Year...

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Color space and alpha issues

[Troy Sobotka]

On Dec 20, 2011 10:41 PM, James Ruan ruanbeih...@gmail.com wrote:
 Certainly, every image entering the
 composite system must indicates its format and outputs a straight
 alpha( actually recommended) to the system.

Recommended?  I would need some citations as just about every industry
compositor I have spoken with prefers an associated alpha representation as
it more closely models an emissive representation of light.

 And actually I don't see any problem to introducing emitting in
 partially transparent image with the format straight alpha.

It cannot be done. Only associated alpha can properly represent emissive
RGB as the over operation becomes an add.

It is fundamentally impossible to express an emissive pixel using
unassociated alpha due to the over operation. Consider emissive yellow such
as that from a candle flame with no opacity:

1,1,0 RGB with 0 alpha.

In an unassociated system, the over operation would be:

(Over.RGB * Over.Alpha) + (Background.RGB * (1 - Over.Alpha)) or
(RGB * 0) + (Background * 1)

Nothing is added. Now consider the identical as expressed with associated:

Over.RGB + (Background.RGB * (1 - Over.Alpha)) or
(1,1,0) + (Background.RGB * 1)

Only in the associated alpha representation does the math result in an
additive scenario. The actual formulas change for associated versus
unassociated.

 When we talk about alpha format, it has two meaning:
 One for file format RGBA is stored as four bytes integer ranging from 0
to 255;

Bit depth has little to do with the representation and implications of the
two classes of alpha.

 The conversion between that two is followed by 0.0 to 1.0 mapping to 0 to
255.

This is subject to color transformations and the non linear
representations. Diffuse white and middle grey values may be varied in some
linear system models, but that is again tangential to the discussion.

 So storing an luminescent partially transparent color image to an
 integer format must use premultiplied alpha format because RGB bigger
 than 1.0 means something and must be remapped to the range of 0 to 255
 multiplied with alpha as a coefficient, so reverse that can get RGB
 bigger than 1.0 just as it is produced.

This is a wee tad confused. ;)

 That's an restriction of
 integer file format not the straight alpha itself.

Despite the above confusion, the conclusion remains incorrect.

 Why blur/defocus and alpha over needs premulitplied format? Can't it
 be represented in straight float without any info lose?

Visualize a two by two grid with red pixels on the left and blue on the
right. If the blue were 0% opaque, a blur would be contaminated by the blue
color as it relies on a window of pixels to achieve the blur. The only
method to achieve a correct blur is via a multiply to knockout the blue to
reduce the blue to zero emission so as to not contaminate the blur. This is
associated alpha.

 I don't
 understand the restriction here.
 Is it possible to care about format only at FILE IO part but maintain
 uniform in the internal representation?

Not quite as again, at various junctures of a composite, an artist might
require both formats to exist simultaneously.

Both associated and unassociated alphas have a role in compositing
depending on artist needs. It is an unfortunately common mistake for
individuals to treat them as interchangeable and synonymous as both feature
unique attributes.

I hope that helps to clarify some of the confusion.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Color space and alpha issues

[Troy Sobotka]

On Wed, Dec 21, 2011 at 11:22 AM, gespert...@gmail.com
gespert...@gmail.com wrote:
 uh, oh! Luminescent premul doesn't seem to be possible in Blender either.
 The alpha-over node seems to be skipping pixels with alpha=0 from the
 second operator.
 http://ubuntuone.com/4vtqL5bN74wMfsBbl9QkMZ

 Troy is investigating the problem and promised a patch for the end of
 the day. :-p

Bug report: 
http://projects.blender.org/tracker/index.php?func=detailaid=29675group_id=9atid=498
Patch:
http://projects.blender.org/tracker/index.php?func=detailaid=29676group_id=9atid=127

It should be noted that Blender generates negative alpha values using
the internal renderer according to Guillermo's demonstration file as a
result of antialiasing procedures, so a Colorramp node was added to
clamp the rendering alpha output.

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Color space and alpha issues

[Troy Sobotka]

James Ruan ruanbeih...@gmail.com wrote:
 The use of premultiplied alpha format is to save some computing time.

This is certainly a byproduct, but not entirely correct for associated
alpha's existence. It is mandatory state for correct convolution
operations and luminescent over adds.

Jeremy Selan (lead architect on OCIO):

First off, I'm 'pro' premultiplication.  To the best of my
understanding, premultiplication is the natural representation of
pixels with alpha; the big confusing thing about it is the name   I
feel the simplest understanding of premultiplication is looking at it
from a rendering perspective. If you're writing a renderer, you ask
yourself how much energy is being emitted from within the bounds of
this pixel?  Call that rgb. and, how much of the background does
this pixel occlude? That's alpha. This is how all renderers work
(prman, arnold, etc) , and its called 'premultiplied'. Note that at no
time does prman have an explicit step that multiplies rgb by alpha,
it's implicit in our definition of 'total pixel energy'. 

http://groups.google.com/group/ocio-dev/browse_thread/thread/65e84a85416a8637/962ea485d1a210a3?lnk=gstq=thoughts+on+alpha#962ea485d1a210a3

Brecht Van Lommel brechtvanlom...@pandora.be wrote:
Both have some annoying consequences, I'm still going back and forth
on this...

I think the discussion is really a yin / yang of balance. If we
evaluate it on the merits of existing technology, it would seem that a
sizable chunk of imaging systems default to the rendering model of
associated.

My only opinion on it is that if we go associated, that keying nodes
and functionality still support unassociated as it makes it possible
to manually recover the background plate data. If we enforce an
associated alpha throughout am I correct in assuming that the output
from such a node would default to a loss of that background plate
data?

With respect,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Color space and alpha issues

[Troy Sobotka]

I thought I'd add the infamous thread over at Adobe here regarding
associated versus unassociated alpha in the context of a system that
needs to support various formats.

In this case, for those unfamiliar, this was the thread in which Adobe
responded to their (mis) handling of the EXR format.

The players here are:

Zap Andersson - seasoned image professional now with Autodesk.
Florian Kainz - architect of the EXR specification.
Chris Cox - veteran architect at Adobe.

http://forums.adobe.com/thread/369637

TL;DR version:

Unassociated alpha systems cannot adequately deal with the inherent
specifics of associated alpha systems.

I've also added a Further Reading section to Brecht's page.

Hope someone finds it insightful,
TJS
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers