Wow! Thanks Matt. I thought I was confused till now - but now it's just mind boggling. The terminology alone makes this whole thing terribly annoying. Far as I'm concerned Linear and Linear half float are just the same thing in lower bit depth, but hey, doesn't seem like it is. Would be nice if at least terminology is standardizes. But that means that all software vendors need to speak the same language, which I doubt will happen.
Thanks again for all the explanations everyone! Ron Ganbar email: [email protected] tel: +44 (0)7968 007 309 [UK] +972 (0)54 255 9765 [Israel] url: http://ronganbar.wordpress.com/ On 28 December 2011 07:50, Matt Plec <[email protected]> wrote: > The "linear" is the original 32 bit int linear that was originally > available from the SDK. This does has some scale to get the output values > between 0 and 1 rather than lots of highlights getting clamped at 1 and > losing all the detail. As far as I know the values do increment linearly, > ie there is no gamma/log curve distributing them unevenly, but they don't > increase at a rate that puts mid gray at 0.18, as they do in the half-float > linear mode where it's possible to represent numbers greater than 1.0 > making this scaling unnecessary. The half float linear mode was added later > and we now use that as the default since it gives a linear that matches > what most people seem to expect linear to be nowadays. > > You'll notice that taking, say, rec709 straight from the Read by setting > that as the r3d gamma curve, and taking half float linear and applying > rec709 separately won't look the same because stuff in the middle has gone > through different paths to become "linear" in the middle. However, setting > the Read to the old 32 bit linear and applying rec709 will match the rec709 > gamma output. > > So this is something you want to watch out for if you've got some shots > that have gone through redcinex straight to, say, rec709, and some that > have gone through comp as half float linear and then got rec709 applied in > the Write from Nuke. I haven't look at recent versions of redcinex so I > can't say if the rec709 output is still the equivalent of "old" linear with > rec709 applied or half float linear with rec709 applied. > > Nothing's ever easy, is it? =) > > Matt > > > > On 21 Dec 2011, at 04:24, Ron Ganbar wrote: > > I'm emailing support about this, maybe they can shed some light on the > difference between Linear and Linear Half Float. > Thanks all for the help! > > Ron Ganbar > email: [email protected] > tel: +44 (0)7968 007 309 [UK] > +972 (0)54 255 9765 [Israel] > url: http://ronganbar.wordpress.com/ > > > > On 21 December 2011 12:41, Fredrik Pihl <[email protected]> wrote: > >> Well, not pushed perhaps, but "mapped" so that a correct exposure >> (depending of chosen ISO) of a gray chart will end up somewhere around 0.18. >> >> A klipping from a conversation I had with Graeme Natress at red shows: >> >> "With linear EXR output, we aim to put mid grey at 0.18 in the EXR file >> as requested by it's inventors at ILM. If you think about it, that gives >> only 2.5 stops or so between 0.18 and 1.0, and in ISO800 where we have >> about 5 stops above mid grey, that's going to generate values in the 0 to >> ~5.7 range. Higher ISOs will produce higher output values, always keeping >> mid grey at 0.18." >> >> >> //fredrik >> >> >> >> On Wed, Dec 21, 2011 at 8:38 AM, Randy Little <[email protected]>wrote: >> >>> 18% grey isn't pushed to .18 .18=18% of 0-1 linear response. >>> 18%grey is what happens if you mix 50%black and 50%white and spin it >>> really fast. You get a scene average reflectance of 18%. The chips >>> aren't reordering more then 16bits INT. the only reason you need/want >>> float is when you start playing with Curves you start remaping the >>> data and in this way you aren't going to lose anything. For Ron's >>> issue my guess is that what he is getting is INT sRGB with the values >>> remapped and in nuke you are getting linear without any remapping of >>> values to fit under 1.0. THUS blacks aren't getting crushed in nuke >>> like they are in redcine. ALL of these is pretty easy to solve with >>> a macbeth cart or a greyscale wedge. >>> >>> Randy S. Little >>> http://www.rslittle.com >>> >>> >>> >>> >>> On Tue, Dec 20, 2011 at 23:20, Simon Björk <[email protected]> >>> wrote: >>> > The term half float linear is a bit of a strange name for a gamma >>> curve I >>> > must say, and it definitely causes a lot of confusion. In this case, >>> from >>> > what I understand, half float linear is a linear curve where 18% grey >>> is >>> > mapped to 0.18. This explains why bright values are pushed above >>> > 1.0. However, I'm not full understanding what's happening. If that was >>> the >>> > only thing that's happening compared to (the old and don't use) linear >>> > option, I would think that you could match the two with a simple >>> multiply. >>> > But you can't. Saturation/contrast is still way different between the >>> two. >>> > >>> > Regarding RedCineX, in newer versions (last year or so) it allows you >>> to >>> > export EXRs with values above 1.0. You don't have the half float linear >>> > option in there, but actually it doesn't matter what gamma setting you >>> > chose. If you render EXRs from RedCineX it will output linear EXRs >>> with 18% >>> > grey pushed to 0.18. >>> > >>> > In my opinion the half float linear option in Nuke should be renamed to >>> > something else. Or just replace the current linear option (which is >>> there >>> > for legacy reasons). >>> > >>> > /Simon >>> > >>> > >>> > 2011/12/20 Deke Kincaid <[email protected]> >>> >> >>> >> Either way the r3d reader set to linear will clamp at 1.0, set to half >>> >> linear float will go beyond 1.0. I don't pretend to know what the >>> red sdk >>> >> is doing under the hood. Half linear float option does not exist >>> under >>> >> redcinex. >>> >> >>> >> -deke >>> >> >>> >> >>> >> On Tue, Dec 20, 2011 at 13:45, Randy Little <[email protected]> >>> >> wrote: >>> >>> >>> >>> clamped to 1.0 or raw data mapped to values between 0-1.0 with 3 >>> >>> places of precision. But I am pretty sure the d/a in every camera >>> is >>> >>> integer and mapping data into integer space for its raw file. >>> >>> http://www.rslittle.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Dec 20, 2011 at 13:37, Howard Jones <[email protected] >>> > >>> >>> wrote: >>> >>> > 1.0 is half float/float even if not clamped ;) >>> >>> > for Ron's question (if I read it right) >>> >>> > >>> >>> > Half float or 16 bit float is a less accurate version of 32 bit >>> float. >>> >>> > AFAIK The float being the floating point part of the number. you >>> dont >>> >>> > save >>> >>> > 123.45678 you save 12345678 with a bit(?) for the position of the >>> >>> > floating >>> >>> > point. >>> >>> > The difference between 16bit (half float) and 32 bit (float) is >>> that >>> >>> > with >>> >>> > 16bit the length of that number gets truncated at a lesser degree >>> of >>> >>> > accuracy compared to 32bit. >>> >>> > You could have 10 or 8bit float if you wanted, just not much point >>> for >>> >>> > what >>> >>> > we do. Similarly you could have 32bit non-float if you really >>> wanted, >>> >>> > but >>> >>> > again no point in our game afaic - as far as I care ;) >>> >>> > >>> >>> > Linear is linear, but again you could put any gamma or other curve >>> in >>> >>> > there >>> >>> > if you wanted. >>> >>> > >>> >>> > http://en.wikipedia.org/wiki/Half-precision_floating-point_format >>> >>> > >>> >>> > Howard >>> >>> > >>> >>> > ________________________________ >>> >>> > From: "[email protected]" <[email protected]> >>> >>> > >>> >>> > To: Nuke user discussion <[email protected]> >>> >>> > Sent: Tuesday, 20 December 2011, 20:24 >>> >>> > Subject: Re: [Nuke-users] Redcine-X VS Nuke >>> >>> > >>> >>> > 1.0 is half float if it encoded half float and clamp to 1.0 >>> >>> > >>> >>> > Sent from myTouch 4G >>> >>> > >>> >>> > ----- Reply message ----- >>> >>> > From: "Deke Kincaid" <[email protected]> >>> >>> > To: "Nuke user discussion" <[email protected]> >>> >>> > Subject: [Nuke-users] Redcine-X VS Nuke >>> >>> > Date: Tue, Dec 20, 2011 12:13 >>> >>> > >>> >>> > >>> >>> > Last I knew RedcineX only outputs EXR to "linear" which caps out at >>> >>> > 1.0, not >>> >>> > half linear float. >>> >>> > >>> >>> > -deke >>> >>> > >>> >>> > On Tue, Dec 20, 2011 at 04:29, Simon Björk < >>> [email protected]> >>> >>> > wrote: >>> >>> > >>> >>> > I might be misunderstanding you, but why the srgb2lin conversion? >>> >>> > RedcineX >>> >>> > only outputs linear exrs so as far as I know you shouldn't use any >>> >>> > colorspace convertions in Nuke if you chose that path. You can test >>> >>> > this if >>> >>> > you try different gamma curves in RedcineX and render to EXR. They >>> >>> > should >>> >>> > all look identical. >>> >>> > >>> >>> > Regarding my earlier post about half float linear gamma setting in >>> Nuke >>> >>> > should match a rendered exr from RedcineX, I just tested this and >>> it >>> >>> > doesn't >>> >>> > seem to work. I'm pretty sure this worked earlier, but I might be >>> >>> > wrong. The >>> >>> > "linear gamma curve" in Nukes R3D importer is an old one and >>> shouldn't >>> >>> > be >>> >>> > used. Not sure why it's still there. >>> >>> > >>> >>> > This whole R3D in other applications often causes problems. Same in >>> >>> > After >>> >>> > Effects. I find that the most reliable solution (still unreliable) >>> is >>> >>> > to >>> >>> > output from RedcineX. >>> >>> > >>> >>> > /Simon >>> >>> > >>> >>> > >>> >>> > >>> >>> > 2011/12/20 Deke Kincaid <[email protected]> >>> >>> > >>> >>> > I forgot to mention that It all depends what file format your >>> >>> > outputting. If >>> >>> > your outputting to dpx or tiff then set the decode colorspace/gamma >>> >>> > curve >>> >>> > the same as RedcineX but in the write node set the colorspace to >>> >>> > "linear". >>> >>> > While working with the R3d though, the viewer will look different >>> from >>> >>> > RedcineX unless you set it to linear. After reading back in the >>> >>> > dpx/tiff, >>> >>> > then you can set the viewer back to srgb and it will look correct. >>> >>> > >>> >>> > If your outputting to Exr from RedcineX then you need add a >>> colorspace >>> >>> > node >>> >>> > with in:sRGB and out:Linear (Read node settings all should match >>> >>> > RedcineX). >>> >>> > While this is technically incorrect but it will give you the >>> >>> > equivalent of >>> >>> > burning the grade into the EXR. >>> >>> > >>> >>> > People here are mentioning using Half Linear Float which does >>> properly >>> >>> > linearize the curve form the chip when going to EXR. You would >>> need to >>> >>> > extract a lut between the linear R3d and your director's color to >>> use >>> >>> > as a >>> >>> > viewer lut and use that in the write node. >>> >>> > >>> >>> > -deke >>> >>> > >>> >>> > >>> >>> > On Tue, Dec 20, 2011 at 00:15, Ron Ganbar <[email protected]> >>> wrote: >>> >>> > >>> >>> > Thanks for this Deke. >>> >>> > The settings are all the same, but looking at the Nuke Viewer set >>> to >>> >>> > sRGB, I >>> >>> > see a very washed out image - what I would normally consider a >>> Cineon >>> >>> > looking image. Looking at the Redcine-X viewer it looks correct. >>> >>> > Any ideas? >>> >>> > >>> >>> > >>> >>> > Ron Ganbar >>> >>> > email: [email protected] >>> >>> > tel: +44 (0)7968 007 309 [UK] >>> >>> > +972 (0)54 255 9765 [Israel] >>> >>> > url: http://ronganbar.wordpress.com/ >>> >>> > >>> >>> > >>> >>> > >>> >>> > On 20 December 2011 09:48, Deke Kincaid <[email protected]> >>> wrote: >>> >>> > >>> >>> > First, try hitting the "Metadata" button in the read node. That >>> should >>> >>> > make >>> >>> > it grab the right color settings. If not you can match the same >>> >>> > settings in >>> >>> > Nuke as the one he has in RedcineX (they should all be named the >>> same). >>> >>> > >>> >>> > Also make sure your using Nuke 6.3v5 because it includes RedGamma2 >>> and >>> >>> > RedColor2 which is missing from versions before that (older SDK). >>> >>> > >>> >>> > -deke >>> >>> > >>> >>> > On Mon, Dec 19, 2011 at 23:34, Ron Ganbar <[email protected]> >>> wrote: >>> >>> > >>> >>> > Hi all, >>> >>> > I don't have a lot of experience with converting R3D files, but I >>> so >>> >>> > far did >>> >>> > it with Nuke and was pretty happy with the result. >>> >>> > However, a director, who is technically minded, just told me that >>> when >>> >>> > he >>> >>> > takes something into Redcine-X and without changing the color at >>> all he >>> >>> > gets >>> >>> > something he likes. I did the same thing, and indeed the image >>> looks >>> >>> > nice. >>> >>> > When I do the same thing in Nuke I get a very washed image. What's >>> the >>> >>> > output colorspace of the Nuke R3D read node? How can I get the same >>> >>> > kind of >>> >>> > output from Nuke's Read node to Redcine-X's output? >>> >>> > >>> >>> > Thanks, >>> >>> > Ron Ganbar >>> >>> > email: [email protected] >>> >>> > tel: +44 (0)7968 007 309 [UK] >>> >>> > +972 (0)54 255 9765 [Israel] >>> >>> > url: http://ronganbar.wordpress.com/ >>> >>> > >>> >>> > >>> >>> > _______________________________________________ >>> >>> > Nuke-users mailing list >>> >>> > [email protected], >>> http://forums.thefoundry.co.uk/ >>> >>> > >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> > >>> >>> > >>> >>> > >>> >>> > _______________________________________________ >>> >>> > Nuke-users mailing list >>> >>> > [email protected], >>> http://forums.thefoundry.co.uk/ >>> >>> > >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> > >>> >>> > >>> >>> > >>> >>> > _______________________________________________ >>> >>> > Nuke-users mailing list >>> >>> > [email protected], >>> http://forums.thefoundry.co.uk/ >>> >>> > >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> > >>> >>> > >>> >>> > >>> >>> > _______________________________________________ >>> >>> > Nuke-users mailing list >>> >>> > [email protected], >>> http://forums.thefoundry.co.uk/ >>> >>> > >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > -- >>> >>> > -------------------------------- >>> >>> > Stiller Studios >>> >>> > Lidingö/Sweden >>> >>> > >>> >>> > Simon Björk >>> >>> > Stiller Studios >>> >>> > +46 (0)8 555 23 560 >>> >>> > Ekholmsnäsvägen 40, S-181 41 Lidingö >>> >>> > [email protected] >>> >>> > www.stillerstudios.se >>> >>> > >>> >>> > find us: >>> >>> > >>> >>> > >>> http://www.eniro.se/query?search_word=stiller+studios&geo_area=liding%F6&what=all >>> >>> > >>> >>> > >>> >>> > >>> >>> > _______________________________________________ >>> >>> > Nuke-users mailing list >>> >>> > [email protected], >>> http://forums.thefoundry.co.uk/ >>> >>> > >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> > >>> >>> > >>> >>> > >>> >>> > _______________________________________________ >>> >>> > Nuke-users mailing list >>> >>> > [email protected], >>> http://forums.thefoundry.co.uk/ >>> >>> > >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> > >>> >>> > >>> >>> > _______________________________________________ >>> >>> > Nuke-users mailing list >>> >>> > [email protected], >>> http://forums.thefoundry.co.uk/ >>> >>> > >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> _______________________________________________ >>> >>> Nuke-users mailing list >>> >>> [email protected], http://forums.thefoundry.co.uk/ >>> >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> Nuke-users mailing list >>> >> [email protected], http://forums.thefoundry.co.uk/ >>> >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> > >>> > >>> > >>> > >>> > -- >>> > -------------------------------- >>> > Stiller Studios >>> > Lidingö/Sweden >>> > >>> > Simon Björk >>> > Stiller Studios >>> > +46 (0)8 555 23 560 >>> > Ekholmsnäsvägen 40, S-181 41 Lidingö >>> > [email protected] >>> > www.stillerstudios.se >>> > >>> > find us: >>> > >>> http://www.eniro.se/query?search_word=stiller+studios&geo_area=liding%F6&what=all >>> > >>> > >>> > >>> > _______________________________________________ >>> > Nuke-users mailing list >>> > [email protected], http://forums.thefoundry.co.uk/ >>> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> _______________________________________________ >>> Nuke-users mailing list >>> [email protected], http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >> >> >> >> -- >> ______________________________ >> Fredrik Pihl >> visual effects supervisor - digital compositor >> +46-708-559 559 >> >> _______________________________________________ >> Nuke-users mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> > > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > > > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
