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: ron...@gmail.com > 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 <fre...@gmail.com> 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 <randyslit...@gmail.com> 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 <si...@stillerstudios.se> 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 <dekekinc...@gmail.com> > >> > >> 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 <randyslit...@gmail.com> > >> 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 <mrhowardjo...@yahoo.com> > >>> 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: "randyslit...@gmail.com" <randyslit...@gmail.com> > >>> > > >>> > To: Nuke user discussion <nuke-users@support.thefoundry.co.uk> > >>> > 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" <dekekinc...@gmail.com> > >>> > To: "Nuke user discussion" <nuke-users@support.thefoundry.co.uk> > >>> > 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 <si...@stillerstudios.se> > >>> > 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 <dekekinc...@gmail.com> > >>> > > >>> > 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 <ron...@gmail.com> 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: ron...@gmail.com > >>> > 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 <dekekinc...@gmail.com> 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 <ron...@gmail.com> 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: ron...@gmail.com > >>> > tel: +44 (0)7968 007 309 [UK] > >>> > +972 (0)54 255 9765 [Israel] > >>> > url: http://ronganbar.wordpress.com/ > >>> > > >>> > > >>> > _______________________________________________ > >>> > Nuke-users mailing list > >>> > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > >>> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > Nuke-users mailing list > >>> > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > >>> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > Nuke-users mailing list > >>> > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > >>> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > Nuke-users mailing list > >>> > Nuke-users@support.thefoundry.co.uk, 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ö > >>> > si...@stillerstudios.se > >>> > www.stillerstudios.se > >>> > > >>> > find us: > >>> > > >>> > http://www.eniro.se/query?search_word=stiller+studios&geo_area=liding%F6&what=all > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > Nuke-users mailing list > >>> > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > >>> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > Nuke-users mailing list > >>> > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > >>> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > >>> > > >>> > > >>> > _______________________________________________ > >>> > Nuke-users mailing list > >>> > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > >>> > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > >>> _______________________________________________ > >>> Nuke-users mailing list > >>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > >> > >> > >> > >> _______________________________________________ > >> Nuke-users mailing list > >> Nuke-users@support.thefoundry.co.uk, 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ö > > si...@stillerstudios.se > > www.stillerstudios.se > > > > find us: > > http://www.eniro.se/query?search_word=stiller+studios&geo_area=liding%F6&what=all > > > > > > > > _______________________________________________ > > Nuke-users mailing list > > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > _______________________________________________ > Nuke-users mailing list > Nuke-users@support.thefoundry.co.uk, 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 > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > _______________________________________________ > Nuke-users mailing list > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
