Welcome to our community

Be a part of something great, join today!

Register Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Very serious RedCine limitation (bug??) when using PDLog685, or am mising something?

I understand your frustration, I really do. The biggest thing I have learned from the RED experience is to take NOTHING for granted.

This is a different beast from anything else ever created so the approach is unique. It's not film, it's not video, so a new set of rules apply.

There is a lot of familiar terminology, but it doesn't always respond the same way we are used to. This shouldn't be seen as a mistake, just a reality.

Rather than water down the sensor image to a point it can be used for anything, RED have given us access to the full sensor data. This in itself changes the way we need to approach it.

There are things we all have to adapt to and relearn to get the most of this process.

I'm not saying you're wrong, I'm just saying to assume RED got it wrong is probably premature.

My advice is to not go in with the assumption that these are mistakes or problems created by the manufacturer, but to better understand the way you need to work with the footage in the world of RED.
 
I thing, to always try to give an excuse to simple things, like the Cineon Log export of REDcine, we don’t assist the effort of RED people, that are trying to bring the camera closer, to people that are making their living by servicing the industry.

I know that, what I found, is a common problem to many of us, as its being evident from the replies to that thread, so the problem is real, and today affects the results of all the productions that are out there. That is a fact.

By try to round it, and put our head in the hole like an ostrich, we wouldn’t help anyone.

I have proposed a simple solution with a curve from within REDCine in order to reallocate the values of REDLog to match these of a Cineon, I have also post a sample table of what could be the correct Cineon values in respect to scene brightness/reflectance so someone that knows the inside/out of REDcine and REDLog can create that curve and post it here. REDcine can save and load curves, so a custom curve can easily be distributed.

If I have to reverse engineer the REDLog and the curves from REDcine, I would need days of testing and probable one or two weeks. And because my time costs I wouldn’t be able to freely distribute it.

My believe is, that Graeme is a very qualified engineer to do that, and for him would be just few hours of work.

I’m at the disposal of anyone, which wants to assist him, or even explain him deeper the idea. My email is Lakis@motionfx.gr.
 
Mike alerted me to this thread the other night at the Aussie Reduser night. Suffice to say that I understand Evangelos' problem, as I'm also trying to get some tests done to attempt to fit the redcode output more neatly into an existing film-finish workflow which has been dominated by Cineon/DPX log for the past 15 years.
When you have dozens of 3D & comp artists lined up to do vfx work, they want an image platform and workflow they understand when they are on tight deadlines to put out complex vfx shots.
We understand fully that Red is not film, nor video, however some of us need to fit it into existing systems which don't include a new hardware/software platform.
From my understanding so far, neither of the current log conversions (redlog/pdlog685) accomplish a BASIC transition to log DPX (or Cineon) that would emulate if the same scene were shot on film and scanned. (happy to be proven wrong on this point). :usd: ... but this is where our artists need the image to be when it isn't going through the hands of a dedicated colourist prior to vfx work being done.
Good luck with your LUT hunt Evangelos. PM if you'd like to discuss further.
regards
Chris
 
Ok guys, I hope this is helpful / relevant. I believe Stu had insider help from RED to achieve these:

http://prolost.blogspot.com/2008/03/red-log.html

I have no film post experience, but from what I understand, these settings can take you from RED Log to pure linear, and then I suppose you're free to interpret that to cineon however you like.

Or maybe you can bypass the cineon standard and work in linear space, depending on your workflow.

Was that useful?
 
DaNni, the solution that’s on the Prolost site is something that we already knew. The redlog is using black at 0 and white at 1023, the weird is the Gamma interpretation which is, on AE is 1,7, on Shake is 0,6 and on Nuke is 1,02… That’s why Cineon is a common ground… But this is not Cineon as it’s being requested from the VFX guys… as Chris is stating, in a very accurate way. This is a redlog. The cineon encoding is related to monitor calibration view LUT’s that are needed in the whole post chain that are already existing.

Moreover the cineon encoding is using two RELATIVE points in a curve that are representing the black point 0,5% reflectance (almost total black) with 95cv and white point 90% reflectance to 685cv both values are NOT absolute, that means, that there are darker blacks below 95cv and match brighter whites than 685cv. Actually above 685cv the curve has a gradually compressing behavior. Now when instead of 685 you have 1023 there is no headroom to compress the highlights so they hard clip, likewise is happening in the blacks. Its understood that with REDLog wont be available a highlight compression area.

A possible workaround, that has being proposed to me from a post house in Denmark, could be the lowering of the white point by adjusting the exposure by -0,5 and export REDlog.

That workaround is “fixing” the white point in a non accurate way but is crashing the blacks because it’s lowering all the points symmetrically. If we create a curve that will lower the white point and also lifting as needed the blacks by keeping the mid tones in the 470cv will be a very close to real cineon workaround. But this is difficult since it needs a RED camera to shot a series of step charts and a try and error procedure to find the correct curve in REDCine.

Still, after three days, no word from a RED support engineer on this public thread…
 
mikes said:
Also Scratch Cine is not $100,000 - it is more like $15 -17,000 I believe. It is vastly cheaper than an SR deck - even with killer Hardware it is around $50- $60 K I believe.
Click to expand...

i wouldnt compare a software to a hardware, especially in this case:
A hdcam vtr is feeded by scratch cine, speedgrade etc.

So its an *additional* hdcam deck, if you want to play out HD dailies.

iirc the small scratch was at 17.5
 
Evangelos Achillopoulos said:
As I have stated in previous message, I'm not an owner so I don't have that privilege. I'm just trying to serve my clients in the best possible way.

So my only getaway is this forum.
Click to expand...

Being a post house that provides RED users and clients with a very important service gives you that privilege.

I would definitely suggest PMing Graeme or Kevin Stanley (the workflow guru). Just because you don't own a RED doesn't mean that you're not benefiting the RED community with your post services... I don't think PlasterCity Digital Post here in Hollywood own any REDs either, but they have a very close relationship with RED. Your call/email would be very important to them.

Contact them directly and share your findings back on the public forum.
 
Evangelos,

I've been following this thread, and honestly - I don't understand your frustration.

There are several curves available to you as 1D LUTs - PDLog685, PDLog985, RedLOG, Rec709, and a few others. Each of these put R3D files into a different output space. Keep in mind that the Cineon curves were designed specifically to maximize dynamic range for *film.* RED is not film. REDLog is a curve that maximizes dynamic range for RED and is close enough to Cineon pipelines that people can easily adjust. If for some reason, you have to force RED *exactly* into a Cineon curve, then yes - you probably have to do a bit of your own work to make it happen.

Quite a few facilities are using RedLOG to feed log-based pipelines for color correction and film output and are very happy with it. I know of several very large VFX facilities with large linear 1.0 and/or log-based pipelines that are happy with what they receive. But all of them have made small tweaks to push or pull RED material in one way or another to accomodate their specific pipelines.

Panalog is nowhere near Cineon. The LUTs available from Thomson for the Viper - also nowhere near Cineon. What they do is provide a way to get Genesis and Viper footage into a useful range that can then be manipulated as necessary.

You say, "If I have to reverse engineer the REDLog and the curves from REDcine, I would need days of testing and probable one or two weeks. And because my time costs I wouldn’t be able to freely distribute it."

Yes. True. And your point is...? What do you think Technicolor, Cineworks, Plaster City, Off Hollywood, and other leaders in RED post-production have done? You CAN use RedLog as a generic starting off point... put a Log-to-Lin curve on it, and it will be pretty close to "right" for a film-out. But a film-out is *never* a generic process. Do you think EFilm just takes Cineon files, throws them into an Arri Laser, and outputs?

What I get from your posts is that RED has not gone to the work of mapping their camera space exactly into a space that they know is not ideal for their footage. You think they should and are pretty annoyed that they have not.

REDLog is a very good way of maximizing range from RED's linear space to a fairly generic log space. It is available for free. Take it, work with it, and make it fit your pipeline.

Lucas
-----
ASSIMILATE, inc.
LA, CA, USA
 
luki said:
What do you think Technicolor, Cineworks, Plaster City, Off Hollywood, and other leaders in RED post-production have done? You CAN use RedLog as a generic starting off point... put a Log-to-Lin curve on it, and it will be pretty close to "right" for a film-out.
Click to expand...

While I get the gist of what you're saying, what you state here is not really accurate. The RedLog curve does not lend itself to this kind of approach, at least not directly. The curve is based on a 0 black point and a 1023 white point, which bears no resemblance to a film curve. If you choose to use the Redlog interpreted files, you need to do one of two things: de-log to linear light, and then convert to Cineon space with a "standard" 95-685, .6 gamma LUT, or use a homebrew curve based conversion in which you implement a reverse log function (rather easily done in something like After Effects), followed by a Cineon lin to log LUT. At this point you will have a reasonably pliable image that you can use with a print preview view LUT, and with proper color correction, get a reasonably good result. What you won't have in most cases is a reasonable starting point, as you would have with a "proper" Cineon log conversion directly from the original data - and as you generally do get with the PD685 LUT, albeit with less information than the RedLog approach. Another approach is to apply a 95-685 LUT to the Redlog image, use color corrector controls to pull the result down into a usable range (primarily the gain and gamma controls), and work basically in video space. This can actually work surprisingly well, but it's only sensible if you are not going to film as your primary deliverable.

For those of us who are using Scratch, all of this is rather moot because we can load the original r3d files and work directly from linear light images to whatever gamma our working color space happens to be (in our case, 2.6 gamma, DCI white point). Since the only deliverable that really requires the image to be in log space is a film deliverable, we use an inverse LUT for that. The whole point of DPX files in any log format is to create RGB images that other programs can understand and preserve as much of the original information as possible, which is better done with log coding. If you can use the r3d files directly, you don't need (or want) to do this conversion in the first place.
 
I think what Evangelos is saying does have a point that goes beyond which exact log / transfer function you are using. If I understand him correctly, he is trying to say that Red PD685/985 logs chop off any highlights after 90% bright (standard white point) so your super whites are no longer there.

If that is indeed the case, then even a conversion from PD685/985->linear->cineon will not help much, besides readjustment of 90% white to its standard value of ~685, since the highlights (super whites) have already been chopped off in PD685/985
 
Joofa said:
I think what Evangelos is saying does have a point that goes beyond which exact log / transfer function you are using. If I understand him correctly, he is trying to say that Red PD685/985 logs chop off any highlights after 90% bright (standard white point) so your super whites are no longer there.

If that is indeed the case, then even a conversion from PD685/985->linear->cineon will not help much, besides readjustment of 90% white to its standard value of ~685, since the highlights (super whites) have already been chopped off in PD685/985
Click to expand...
Not quite, and this confused me for a little while also. The full DR of captured image is transferred to a "log" file (depending on your RA/RC settings, of course) using either/any of the log curves provided. Nothing is "chopped" at this point, given your transfer settings pull the highlights back (reduce ISO or exp val by -0.4 min)
Redlog transfers 0-1.0 of image data to 0-1023 (via a 16 bit transfer lut) using a gamma curve.
PDlog685 transfers 0-1.0 of image data to 0-685 (via a 16 bit transfer lut) using a different gamma curve.
PDlog985 does similar thing too, but I just dont understand it's potential use at all.... crazy increase of the black levels.(?)

While the gamma curve used for PDlog685 looks the "most correct" of the various options when images are viewed on a standard film DI platform (projected light, Truelight calibrated), the problem for a film finish is that it puts your peak highlights at 90% white (685cv) which is NOT peak white on film, you need to get further up above say 850cv to start getting a cleaner highlight (white). This means re-expanding your DR back out from the now compressed range of 685cv to 850-1023cv.
Redlog under the same viewing conditions appears to have too much contrast.

Chris
 
Hi John.
If you'd shot that chart both on film & Red, over/underexposed both systems, then scanned the film to 10 bit log for comparison, then it'd be very useful... ;-)
cheers
Chris
 
Thanks mmost…

So Lucas lets all buy a Scratch to do our job… its good business for you… Bad business for the SCRATCH ONE camera… ooops, RED ONE…

Sorry for the sarcasm… but I can’t help it.

Lucas to understand the extend of the problem; see how the histogram of a RED looks in comparison to others on my Lasergraphics Producer… it needs shaving… or a good hair cut…

1, 2 is RED graded for Cineon – 3,4,5, is Varicam direct capture from AJ-HD1400 in Cineon Gamma correction – 6,7 is 2K Film scan Graded for Cineon.

All this is due bad log encoding… I suppose… I cant accept that a Film REC mode with encoded on a DVCPRO-HD 4:2:2 codec in 8 bits has done so much good job against, an 4:4:4 12 bits RAW codec in 4K… the same histogram has a F900R in HG4 (like RED’s and worst)…

Ofcourse all this is happening when im trying to handle the material in Log space if I just print VIDEO there all looking similar, but again RED is for VIDEO or for Cinema?

Kodak in early 90’s when invented Cineon did a huge research that wasn’t for nothing; the table that I have posted on the first post of that thread is the guide for correct scene brightness to code values conversion for a proper Cineon file

The gamma curve mite look correct, but it isn’t… that’s my opinion. The Pd Log685 really chops off the highlights…

Chris the charts from Jbeale are helpful, but this has to be done differently, the film shoot along with RED is a good idea, but not scientifically correct. I thing the guys from RED know what they have to do.
 
Joofa, lets say that we have linear light of 12 bit, so 0 to 4095 and we want to squeeze them in 10 bit. In order to do the 10bit Log from 12bit linear image data.

A). We need an exact linear data table with on Y axis scene brightness, from the absolute dark to the brightest white, to the point that the sensor clips. We normalize the exposure in an optical way (aperture of the lens) to bring the top white to the 4095 value of the sensor. The data table must have values of scene brightness from 0 to 4095 which 0 is the total darkness and 4095 is the just clipped white. In example to have a light source that can give as from 0,1Cd/m2 to 409,6cd/m2 and we are measuring the scene brightness and the corresponding sensor value. The light has to be flat and constant Kelvin thru the whole curve. This can be achieved with a calibrated transmitive step chart.

B). Now we have a data table of linear light measurements. The next step is to find which values are the corresponding ones to black level of 3%, gray of 18%, and white on 90%, scene brightness, that information I don’t have it… If we have that info the next step is to create a look up table that connects the correct values from the 4096 steps table to the 1023 step table following the table I posted on the start of the thread.

Now it’s understood that some values from 0 to 4095 will be excluded because they don’t fit to the 1023, the question is which points in the scene brightness curve/ sensor data would be out?

If the wrong values are selected then the recreation of the curve will have holes with no info… because the log transform will have missing steps. That is what I see in my histogram… and that’s why the Cineon encoded curve is a must.

There are things that are a big unknown to me also for instance the mention of reflectance is 18% on the gray card, and I have measure it with a reflectometer, also the 90% white it is like that on a reflectometer, but how these values are translated to real light level i.e. in LUX or in CD/m2 ? do you have an idea?

Also there is a possibility that the sensor its not behaving linearly to all the light levels so thats why we have to take scene brightness as a guide and not the values of the sensor. thats the reason to have the first table.
 
You must log in or register to reply here.
Back
Top