…Flame and floating point ?

[Anonymous]

Hi guys,

Is there a way to have Flame work in Floating point ?

Thanks a lot…

Alfafa

[Fusion CIStudios]

You’ll need to work with a 3Dlut. Flame is 12bit but if you apply a 3dLUT you can get floating point results.

[McArdell]

As I recall there was a technology demo at NAB users group showing a flame doing floating point… no date given as to when we might see that.

Jeff

[Noriaki]

Never heard about this 3Lut.
How do you set it up ?

Thanks…

[Fusion CIStudios]

Dig into the Colour Management with LUTs chapter in the Flame manual. Lots of great info in there. [/i]

[Noriaki]

I’m working with 8.5…

And there is no info about 3D Lut, neither in the CC chatper nor CW chatper.

I also went on Discreet web site to check the new release and no info about 32bits or floating point calculations.

Alfafa.

[bnw]

Flame can’t work internally in float. I think maybe what iraflowers is getting at is that if you have the right kind of 3D viewer LUT, you could work in such a way that superwhites and subblacks were preserved, which is a big advantage of true float processing. For example, if you work on log images with FilmVis turned on, what you see on the screen is only a subset of the full luminance range in the image – you can bring (some) detail back from the shadows and highlights.

Maybe someone could make some custom LUTs which could allow you to work with 10 bit material in a 12 bit space, with the extra two bits used to quadruple the dynamic range instead of just providing finer quantisation steps like they usually do. This is all conjecture, and such a setup would likely make colour correction controls work even wonkier than they do in linear, and layering look even worse than in log!

[Noriaki]

Thanks loops for your help.

I think we should put pressure on Discreet to come up with a solution for this limitation.

Alfafa.

[Sinan]

Alfafa wrote:

I’m working with 8.5…

And there is no info about 3D Lut, neither in the CC chatper nor CW chatper.
Alfafa.

3Dlut support has started with inferno_6 / flame_9

[Sinan]

loops wrote:

Flame can’t work internally in float. I think maybe what iraflowers is getting at is that if you have the right kind of 3D viewer LUT, you could work in such a way that superwhites and subblacks were preserved, which is a big advantage of true float processing. For example, if you work on log images with FilmVis turned on, what you see on the screen is only a subset of the full luminance range in the image – you can bring (some) detail back from the shadows and highlights.

Maybe someone could make some custom LUTs which could allow you to work with 10 bit material in a 12 bit space, with the extra two bits used to quadruple the dynamic range instead of just providing finer quantisation steps like they usually do. This is all conjecture, and such a setup would likely make colour correction controls work even wonkier than they do in linear, and layering look even worse than in log!

All the compositing tools in flame, work in linear space. So the contrast function in the color corrector, is not adjusting the contrast as you would expect when you apply it to a log image. This also applies to blurs, blending, etc… What you should do is, you have to convert your log images to linear space, and do your comp, CC, etc… And at the end, just use the inverse of your log2lin lut, to convert the resulting image back to log. And when comping/color correcting the image, you should always use a 3Dlut preview for your monitor. This way, you might get a close preview of the 35mm projector.

But this log2lin process is not lossless. Because 10bit log data, can not be converted lossless to 12bit lin, and converted back to 10bit log. We would need at lest 16bits for representing 10bit log images in linear space.

So I sometimes work on log images directly. But if I really need the comp tools work correctly (like blur, blending modes..), then I convert the images to linear for working in flame/inferno.

[bnw]

kuban wrote:

So I sometimes work on log images directly. But if I really need the comp tools work correctly (like blur, blending modes..), then I convert the images to linear for working in flame/inferno.

Ah, but do you actually convert to *true* linear, or to a gamma encoded video space? 🙂 Personally I don’t like the way midtones adjustments work in truely linear space at all, and if something’s already log I might as well leave it there and view it through a LUT. It’s not that different to what looks “normal”, ie video space.

I know that technically lift/gamma/gain aren’t behaving correctly when used on log images, but I don’t, basically, care. It’s all about the feel of the controls, not whether your white point adjustment is physically correct 🙂 In any case, those controls aren’t physically correct in a gamma encoded space like Flame normally works in either. Your man Stu speaks more coherently about this than I ever could:

http://prolost.blogspot.com/2006/06/know-when-to-log-em-know-when-to-lin.html
http://prolost.blogspot.com/2005/05/log-is-new-lin.html

What I suggested above with a 3D LUT is exactly what eLin did in AfterEffects prior to true float support in version 7. Log-to-lin would be even more destructive than log-to-video in 12bit, so it’s probably not a great plan in Flame.

[Michael Dalton]

@loops 22147 wrote:

Ah, but do you actually convert to *true* linear, or to a gamma encoded video space? 🙂 Personally I don’t like the way midtones adjustments work in truely linear space at all, and if something’s already log I might as well leave it there and view it through a LUT. It’s not that different to what looks “normal”, ie video space.

I know that technically lift/gamma/gain aren’t behaving correctly when used on log images, but I don’t, basically, care. It’s all about the feel of the controls, not whether your white point adjustment is physically correct 🙂 In any case, those controls aren’t physically correct in a gamma encoded space like Flame normally works in either. Your man Stu speaks more coherently about this than I ever could:

http://prolost.blogspot.com/2006/06/know-when-to-log-em-know-when-to-lin.html
http://prolost.blogspot.com/2005/05/log-is-new-lin.html

What I suggested above with a 3D LUT is exactly what eLin did in AfterEffects prior to true float support in version 7. Log-to-lin would be even more destructive than log-to-video in 12bit, so it’s probably not a great plan in Flame.

The old debate. It seems to me that all roads lead to Rome on this one. I personally like Nuke approach of, “What is it?… OK, we’ll convert that to sRGB.” When you’re done, push out what ever encoding you need. Simple and nice and real world friendly. If you want to just go log/log you can do that as well – there are definitely tools there that work as they are supposed to but for the most part there’s not really any large gains in not converting when you’ve got real colour management and a float workspace to muck around in.

One thing I found quite interesting about – of all tools – Quantel’s iQ, is that the compositing and colour environments actually obey the log flag of the current working files and do all the math behind the scenes to get the results to work correctly. Cineon back in it’s day did the exact same. You would request and operation, the softwre would bang everything into sRGB, perform the calulation and transcode the result into log enoded. Nice simple and neat. Beg’s the question a little why AME hasn’t moved a little in the direction.

Of course this has little to nothing to do with the the orignal question of Flame and Float… a move in Flame to Float would need to be more than just having all of the modules support full, it would need to also be full on channel support as well, a rewriten render that processes in GPU in half or full and isn’t relying on OGL as much… all of this is a little down the line I would say. 2008 at least has given us the possibility to import half and convert to 12 with a lut… so there is the beginnings of workflow in place. Hopefully 2009 will show a little more in that arena.

Best,
Chris

[Nitin Bansal]

@cnoellert 24206 wrote:

I personally like Nuke approach of, “What is it?… OK, we’ll convert that to sRGB.”

Nuke’s got a nice sweet system for that. but it’s actually not converting and working in sRGB space of course. It’s converting everything to Linear linear. The real Linear. AKA “Linear Light” The one where gamma is 1, and it looks dark on your monitor if you view it raw. It’s only converting to sRGB in your viewer so that it looks right on your monitor.

I’m sure you meant that, but it’s easy to confuse the masses. Nuke actually works exactly like eLin in AE.

From my experience in Flame, in case anyone’s chasing this one, I would NOT attempt to comp in Linear Light (Gamma 1). Because at 12bit, you’re likely to quantize like crazy in Linear Light, and you’d have to whip up your own LUTs to do anything anyway. And the Half-float that is presently being shopped in the Flame doesn’t apply to anything that you would actually want float for (unless de-interlacing looks magically better in float). So in Flame, you should probably stick to comping in Log, and working under a 3D LUT if you’re reaching for the stars in that box.

Seems to be what everyone is doing anyway.

-ben

[Michael Dalton]

Should have been more clear regarding Nuke… was only talking about the viewers. As far as Flame’s support for Half, considering that in 2010 everything except for the original keyer now supports half, there definitely are advantages in CG pipelines to going float. For straight out 2d comping, cpd with a lut in 10 is totally fine.

Best,
Chris

[Anonymous]

Dear Alfafa

You should use correct 3D viewer LUT. It’ll give u right float processing.

[Author]

Posts