| 00:00 | dmjnova | left the channel |
| 00:01 | dmjnova | joined the channel |
| 00:05 | ItsMeLenny | joined the channel |
| 00:17 | dmjnova | left the channel |
| 00:23 | mithro | joined the channel |
| 00:52 | cfelton | joined the channel |
| 01:07 | dmjnova | joined the channel |
| 01:25 | fsteinel_ | joined the channel |
| 01:28 | fsteinel | left the channel |
| 01:59 | rhavan_ | joined the channel |
| 01:59 | rhavan | left the channel |
| 01:59 | rhavan_ | changed nick to: rhavan
|
| 02:52 | troy_s | joined the channel |
| 04:14 | dmjnova | left the channel |
| 04:38 | dmjnova | joined the channel |
| 08:56 | niemand | joined the channel |
| 09:20 | fsteinel_ | changed nick to: fsteinel
|
| 09:21 | ZeroQ | joined the channel |
| 09:25 | ZeroQ | left the channel |
| 09:34 | niemand | left the channel |
| 10:39 | ItsMeLenny | left the channel |
| 10:54 | Bertl | off to bed now ... have a good one everyone!
|
| 10:56 | Bertl | changed nick to: Bertl_zZ
|
| 11:21 | ItsMeLenny | joined the channel |
| 11:46 | se6astian|away | changed nick to: se6astian
|
| 11:55 | se6astian | changed nick to: se6astian|away
|
| 12:31 | niemand | joined the channel |
| 12:55 | se6astian|away | changed nick to: se6astian
|
| 13:53 | niemand | left the channel |
| 15:25 | niemand | joined the channel |
| 15:36 | niemand | left the channel |
| 15:39 | ItsMeLenny | left the channel |
| 17:19 | Bertl_zZ | changed nick to: Bertl
|
| 17:19 | Bertl | morning folks!
|
| 17:21 | se6astian | hello :D
|
| 19:38 | aombk | hi
|
| 19:43 | rhavan | left the channel |
| 19:45 | rhavan | joined the channel |
| 19:46 | fsteinel | hi
|
| 20:03 | intracube | evening
|
| 20:03 | intracube | has anyone used flowblade?
|
| 20:24 | troy_s | intracube: Nope. Seen it.
|
| 20:50 | intracube | troy_s: yeah, I've been watching a few video tuts. looks very promising
|
| 20:50 | intracube | with the inclusion of ripple/roll tools
|
| 20:52 | intracube | shows they're going for the important things
|
| 20:53 | intracube | instead of 1980s barn-door wipe effects
|
| 20:58 | troy_s | intracube: Important things is not fscking around with damn codecs and crap.
|
| 20:58 | troy_s | intracube: Just cut dammit. Just cut.
|
| 20:58 | troy_s | intracube: The chat I had in PiTiVi was blood rising.
|
| 21:02 | intracube | troy_s: ^ I missed that
|
| 21:02 | troy_s | intracube: It was ugly.
|
| 21:02 | intracube | but as long as it can read a few key codecs like prores
|
| 21:02 | intracube | heh
|
| 21:03 | troy_s | intracube: I suggested a simple damn thing which was A) How is your color blending handled?
|
| 21:03 | troy_s | And I looked after was linked to the code.
|
| 21:03 | troy_s | The code in gstreamer (IIRC) basically does a (telltale idiocy when things are labelled YUV :) ) rgb_to_yuv
|
| 21:03 | troy_s | as in the blends are done on a hard coded rgb to YUV transform.
|
| 21:04 | troy_s | WHICH, if it were an offline editor, is no big ass deal. It's all proxy crap.
|
| 21:04 | troy_s | BUT, it aims to be an online thing... so let me see... here's my thought process immediately:
|
| 21:04 | troy_s | IF it is a hardcoded RGB to YCbCr transform:
|
| 21:04 | troy_s | 1) It is broken. It needs to abide by the source YCbCr obviously.
|
| 21:04 | troy_s | 2) It is broken. It needs to linearize the values to display linear before compositing.
|
| 21:05 | troy_s | Etc.
|
| 21:05 | troy_s | To which I was (thankfully) educated on the fact that color is subjective.
|
| 21:05 | troy_s | No shit.
|
| 21:05 | intracube | didn't realise it did compositing
| | 21:05 | troy_s | The lead developer actually linked me to a video where it describes how color is subjecive.
|
| 21:05 | troy_s | Compositing == blending
|
| 21:05 | troy_s | As in dissolves
|
| 21:05 | troy_s | fades
|
| 21:05 | troy_s | overs
|
| 21:05 | troy_s | anything
|
| 21:06 | troy_s | That's compositing. Not what you expect when you hear "Compositor" per se of course, but the composition of images.
|
| 21:06 | intracube | oh, isn't gamma encoded more suited to crossfades like that?
|
| 21:06 | troy_s | Think about that for a second.
|
| 21:06 | troy_s | It is precisely similar to gradients actually.
|
| 21:06 | intracube | so they appear 'linear'
|
| 21:06 | troy_s | On one hand, if our interface uses a linear line
|
| 21:06 | intracube | thinks we already had this discussion :)
| | 21:06 | troy_s | to indicate a crossfade
|
| 21:06 | troy_s | Yep.
|
| 21:06 | troy_s | But worth revisiting because it has all sorts of cool little bits in it.
|
| 21:06 | intracube | eh, but not right now maybe :)
|
| 21:07 | troy_s | Crossfade from A to B with a linear line UI.
|
| 21:07 | troy_s | Middle might be assumed to be about 50% perceptual intensity. But the colors don't mix correctly unless they are display linearized. Enter problem. :)
|
| 21:08 | intracube | troy_s: https://www.youtube.com/watch?v=oSgnnkraMIg
|
| 21:08 | intracube | gamma encoded text fade on the left, true linear on the right
|
| 21:08 | intracube | actually, the right might be Log
|
| 21:09 | intracube | pretty sure it is...
|
| 21:09 | troy_s | The solution isn't quite as easy to see initially: A) Take the spline, and IF it is assumed to be representing a perceptual intensity spline, run that through the inverse transfer curve to bend the spline values to linearized format. B) Blend on linear reference color values according to that value. :) )
|
| 21:09 | intracube | but same difference I think
|
| 21:09 | troy_s | Their log is screwed
|
| 21:09 | troy_s | Log has a white value generally
|
| 21:09 | intracube | "Take the spline, and IF it is assumed to be representing a perceptual intensity spline, run that through the inverse transfer curve"
|
| 21:09 | troy_s | their upper limit didn't get reached to it.
|
| 21:09 | intracube | yeah, you mentioned that last time :)
|
| 21:09 | troy_s | I suspect they took an sRGB image and rolled it to a log2 or something? Leaving too much headroom.
|
| 21:09 | intracube | still adds complexity - user might want to remain oblivious to that level of whats going on
|
| 21:10 | intracube | 'behind the scenes'
|
| 21:10 | troy_s | Well it depends.
|
| 21:10 | troy_s | I don't ever see a user. I see an artist or experienced peep generally.
|
| 21:10 | troy_s | And the bottom line is that you can sort of "hide" that.
|
| 21:11 | troy_s | Assumption A: That the artist expects a bargraph / UI element to be a perceptual human oriented thing. B: That the artist expects correct blending.
|
| 21:11 | intracube | still finds blender's handling of linear gradients frustrating
| | 21:11 | troy_s | Gradients are deadly tricky in the same way
|
| 21:11 | intracube | but this is #apertus - not going to complain about that here
|
| 21:11 | intracube | :)
|
| 21:11 | intracube | and food is imminent
|
| 21:11 | troy_s | It's all relevant really. Color and imaging and such.
|
| 21:11 | troy_s | Gradients have to track in linear color for the color traversal
|
| 21:11 | troy_s | Be it opponent or tri-color.
|
| 21:11 | troy_s | But the intensity needs to be likely perceptual in many instances
|
| 21:12 | troy_s | So it is the same idea - take the values and run them inversely through whatever perceptual / ldr intensity transfer is used, then march through the linearized colors.
|
| 21:12 | troy_s | Often implementations only do HALF of that, or worse, neither.
|
| 21:15 | intracube | yep
|
| 21:15 | intracube | would be good if Blender could have a gamma transform toggle for the gradient texture
|
| 21:15 | intracube | for example
|
| 21:20 | troy_s | intracube: The problem is that I guess folks get very confused with color very quickly. Or rather, these sorts of things are an immediate and visceral "What you thought you knew about color was totally wrong" feeling.
|
| 21:21 | troy_s | intracube: I'm just about to begin my second pass on the color wheels, which have, shocker, the same issue.
|
| 21:22 | troy_s | intracube: My brain hurts though. I'm unsure exactly the correct approach.
|
| 21:22 | troy_s | I want to take the circular part with the colors laid out (which are effectively linearized reference values) roll them through the inverse of the artist-selected transfer curve (so they are correctly nonlinearized)
|
| 21:23 | troy_s | then roll them through the output transform. But then you can have a mismatch. Example - roll them through a log inverse, then they go to sRGB is... erf. Not sure it really is an issue is the issue. :)
|
| 21:24 | intracube | head explodes
| | 21:24 | intracube | do you mean color picker or compositor 3 point color correction?
|
| 21:30 | intracube | troy_s: but good luck battling the code
|
| 21:30 | intracube | and sergey :P
|
| 21:32 | troy_s | I mean the HSV wheel.
|
| 21:32 | troy_s | You know the picker?
|
| 21:32 | troy_s | The round thing with the value slider?
|
| 21:32 | troy_s | Same sort of issues where the two halves of color collide into a complex little cocktail.
|
| 21:33 | troy_s | intracube: An HSV wheel needs to be color corrected. For screen (display corrections) and for general colorspace transforms (from a different gamut to the output gamut)
|
| 21:35 | troy_s | intracube: So that means you have to roll it through the transforms. The problem is, if you lay it out in display referred values, 0..1, you are already assuming it is in a suitable for display format, aka nonlinear. If you roll that through the output transforms, well you get a doubleup and that's ghastly.
|
| 21:37 | intracube | continue in #blendervse ?
|
| 22:40 | se6astian | time for bed
|
| 22:40 | se6astian | good night
|
| 22:40 | se6astian | changed nick to: se6astian|away
|