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

[Evangelos Achillopoulos]

The defacto standard for years on film out is the Cineon 10bit Log files.

When we want to scan film, we using the Cineon format or the DPX variant in which the code values are between 0 and 1023 (with black point 95 and 90% reflectance white to 685). Cineon format is designed to compress 14bit -16bit linear light values to 10bit Log.

The problem is the following:

We had a test shot today for a big spec spot ad, tomorrow we will do the actual shooting with three RED’s, using the latest firmware ver.15. The test footage that we shot was having deep blacks and just clipping whites. Because we will filmout the final cut, of the ad, to camera negative, I requested the whole workflow to be in Log 10bit DPX, in order to preserve the full information captured by the camera.

When I export the sequence from RedCine using the PDLog685, I noticed that the histogram was limited between 95 and 685 code values, which was very weird to me, since I have a great experience of what a good histogram is (because of my film DI experience), when it’s properly encoded to Log.

I tried to change the ASA from 100 to 320, in order to boost the highlights, and instead, to have the brightest white above 685 code value, RedCine squeeze all the white area just below or exactly in 685 value, so all the highlights ware clipped!

Normally it should be possible to send the white above 685, with NO clipping!

And that’s typical… The 685 white point, it’s just the 90% reflectance white. There are reflectance or scene brightness well above 90% in real life…

The following table shows some of the valid code values of Cineon in respect of light reflectance and negative film density.

Scene 	        Negative        Cineon
Brightness	Film		Code
(reflectance)	Density	        Value

1%		0.00		95
1%		0.01		102
1%		0.02		107
1%		0.05		122
2%		0.11		151
2%		0.17		180
3%		0.23		212	Kodak gray card Black patch
4%		0.30		244
5%		0.36		277
6%		0.43		309
7%		0.49		341
9%		0.56		373
11%		0.62		406
14%		0.69		438
18%		0.75		470	Kodak gray card Gray patch
23%		0.81		501
29%		0.87		531
36%		0.93		562
45%		1.00		593
57%		1.06		624
72%		1.12		654
91%		1.18		685	Kodak gray card White patch
114%		1.24		716
144%		1.30		746
181%		1.36		777
229%		1.43		808
288%		1.49		839
363%		1.55		869
457%		1.61		900

As it’s being evidenced from the above table cineon values are NOT limited to 685 value.

When using RedCine to export Cineon Log encoded DPX files the only selection is PDLog685.

The PDlog985 is not an option, since what it’s doing its just expands the white value, so when the white was on 685 now it’s being lifted to 985, and still clips everything.

Actually its very difficult to clip DPX 10bit Log, almost impossible, I personally haven’t seen higher value than 950 even with Fujifilm Eterna 500, which has more than14 stops latitude… so why REDcine clips in 10bit Log?

What’s wrong?

Why can’t we have a proper full Cineon Log space from RedCine?

Graeme, Lucas (Assimilate) please explain. Am I wrong?

 

[Sebastian Tatut]

How About Red Allert?

How About Red Allert?

Did anyone test if this applies to Red Alert too?

 

[Mike Seymour]

Where to start... your email highlights a number of issues the post community has with RED and a fair few assumptions that we should address. But believe me you are not alone I have had this chat with a dozen people.

1. yours is a common misconception, and really highlights a bunch of issues re people's expectation of RED 685.

2. So first of all you are treating the ISO the wrong way. You want to go from 320 to say 200 to capture possible highlight information, (then you may want to use DRX to even the round off into clip. going from 100 to 320 will clip more harshly

3. The values in say rec 709 are effective 12 bit video gamma/linear - this data (not withstanding the trick above) is the full linear sensor information with a video gamma curve. You can map the same linear data into log space 10 bit - but that relies on the concept that 10 bit log = 12 bit linear (which it sort of does)

4. The best log format is REDLOG it takes into account all the subtle sensor sensitivity issues and it was the first LOG file from the RED team. It works really well - except you need to make a LUT for it. If you don't make and use a REDLOG LUT and use some other LUT , it will no doubt look wrong.

5. As too many people seem unable or unwilling to make a LUT correctly Red made a quick and simple PD685 version of the data that maps the 12 bit linear to a range similar to but not exactly the same as you might expect with a cineon scan. It was not intended as a film equivalent LOG file format - it was just designed so people who could did not yet have time to solve the issue fully could do some quick and simple work. And it works well like that. But it is a rough approximation.

6. Before anyone posts RED should provide all the LUTS
- remember this - this would be a camera company providing a HUGE range of software LUTs and this is way beyond something they should or could do. Compare to Panavision and the Panalut - we all had to work that out too and it was no more or less complex. And the F23 - with their complex Hyper Gamma curves on say Speed Racer... it is all professional stuff we all deal with in major pipelines.
PLUS you dont need to work LOG - it is only for those who want to work log for their own professional reasons.
So if you have a Complex LOG pipeline it is assumed you understand LUTs and are happy to work with them. But again no need to - a 12 bit linear file has ALL the information going, using LOG files in NO way increases the bit depth or grading latitude.

7. You discuss having more latitude in the highlights from a film scan - yes that is correct. The digital file stops way earlier than a well exposed piece of film. It does on the Genesis, f23 and RED

8. RED does not have 14 stops of latitude. Welcome to digital cinematography (it also does not have weave and float, despotting, hairs in the gate or film grain) ... so nothing is perfect

9. You ask "Why can’t we have a proper full Cineon Log space from RedCine?" - heres why - it is not film.
Also it is not based on scanners of film - or film dynamic range it is based on a linear not log response curve and a sensor not film.

I so seriously hope this comes off helpful and not annoying - please accept my remarks in the helpful way I intend them. If I can help further please just ask.

Mike

fxphd.com

 

[Evangelos Achillopoulos]

Mike thanks for your explanation, but allow me to clear up few things…

I thing that the answer to my post, has to came from the really responsible people of RED, that are the makers of the tools that we use, in order to make the most out of their cameras.

So I can accept your POV, but you are ASSUMING things as I…

1. yours is a common misconception, and really highlights a bunch of issues re people's expectation of RED 685.

I don’t thing that I have a “misconception”, Graeme said to a post that for film out the PDLog685 is the way. So I should expect a real Cineon behaviour just after REDcine… not a soup up version of Cineon Log!

And really this is a very simple thing to do software wise… I’m an engineer and I know what I need, to do it. But am not the manufacture of the camera and I don’t have to invent the wheel every time… in order to do my job. If they pay me I can tell them how to do it, but by seeing what they have achieved until now, in terms of engineering, I can’t accept the theory that they can’t have a proper Cineon output from REDcine…

Because if this is the case then we are :rip_1: …

2. So first of all you are treating the ISO the wrong way. You want to go from 320 to say 200 to capture possible highlight information, (then you may want to use DRX to even the round off into clip. going from 100 to 320 will clip more harshly

The RAW data on disk are not clipped no matter what I do “In post” so because I had wrong mapping of code values in the PDlog685 I tried to lift the white by changing in post ASA… but apparently this is where I realized that REDCine doesn’t have a proper Cineon Log output…

3. The values in say rec 709 are effective 12 bit video gamma/linear - this data (not withstanding the trick above) is the full linear sensor information with a video gamma curve. You can map the same linear data into log space 10 bit - but that relies on the concept that 10 bit log = 12 bit linear (which it sort of does)

Mapping the 10 bit linear video data to a Log space will result to a weak Log histogram similar to what is happening when we all trying to do this workaround with an F900R i.e.. A Varicam used in Filmrec mode, with a AJ-HD1400 VTR as a player, setup with Cineon850 conversion curve (in the menu item 693) will give a heavy histogram similar to a negative scanned and with code values that are reaching 850. The F900 or any REC709 camera with lin to log conversion is resulting to a WWWW looking Log histogram. Never the less the 10bit log is at least 14bit linear. And by any means 10bit linear can’t carry 12bit linear info…

4. The best log format is REDLOG it takes into account all the subtle sensor sensitivity issues and it was the first LOG file from the RED team. It works really well - except you need to make a LUT for it. If you don't make and use a REDLOG LUT and use some other LUT , it will no doubt look wrong.

Where can we find that LUT? Do we have to guess it? Or I have to reverse engineer the REDLog?

5. As too many people seem unable or unwilling to make a LUT correctly Red made a quick and simple PD685 version of the data that maps the 12 bit linear to a range similar to but not exactly the same as you might expect with a cineon scan. It was not intended as a film equivalent LOG file format - it was just designed so people who could did not yet have time to solve the issue fully could do some quick and simple work. And it works well like that. But it is a rough approximation.

I believe, unable… unwilling??? So if it’s not Cineon what it is? It’s a new invention? The film out is NOT a simple job! Rough approximations are just non professional.

6. Before anyone posts RED should provide all the LUTS
- remember this - this would be a camera company providing a HUGE range of software LUTs and this is way beyond something they should or could do. Compare to Panavision and the Panalut - we all had to work that out too and it was no more or less complex. And the F23 - with their complex Hyper Gamma curves on say Speed Racer... it is all professional stuff we all deal with in major pipelines.
PLUS you dont need to work LOG - it is only for those who want to work log for their own professional reasons.
So if you have a Complex LOG pipeline it is assumed you understand LUTs and are happy to work with them. But again no need to - a 12 bit linear file has ALL the information going, using LOG files in NO way increases the bit depth or grading latitude.

I don’t want to have a specific LUT for my set up. I just want to have the 1D LUT that converts the REDLog to a proper Cineon Log. I know that manufactures that care they do give a LUT to convert to Cineon as Thompson did with Viper, as Panasonic is doing for years with the Gamma Box or the AJ-HD1400, 1700 the Panasonic monitors etc. Sony was following the same arrogant behaviour like RED is doing. Sorry that I’m so aggressive but I thing that a Digital Cinema camera should be following the typical Cineon Log workflow and not a TV workflow that REC 709 is.

Also their is no such thing like "Complex LOG pipeline", I just have a common Cineon Log workflow, as many of us, that working with film the last 20 years...

7. You discuss having more latitude in the highlights from a film scan - yes that is correct. The digital file stops way earlier than a well exposed piece of film. It does on the Genesis, f23 and RED

No am not asking for more latitude, I just want what I have shot (and its on the RAW file) to be also on the output file, and that is possible with either Tiff 16bit or DPX 10bit Cineon Log which is an industry standard. I don’t prefer Tiff because I need 40% more disk space.

8. RED does not have 14 stops of latitude. Welcome to digital cinematography (it also does not have weave and float, despotting, hairs in the gate or film grain) ... so nothing is perfect

I never ask for 14 stops from the camera… (probably in my dreams) I just said that Cineon Log its being designed to accommodate 14 stops. So the 7 - 8 stops of RED can fit the Cineon Log space easily.

9. You ask "Why can’t we have a proper full Cineon Log space from RedCine?" - heres why - it is not film.
Also it is not based on scanners of film - or film dynamic range it is based on a linear not log response curve and a sensor not film.

If its so, why I can have it i.e. from Varicam with a click of a button? Varicam it’s not a film camera either… And when am asking “full Cineon Log space” I mean not limited to 685cv to be able to reach 800cv, 900cv whatever is the max scene brightness of the camera. I don’t expect to get film numbers like 950cv or more…

Mike I do accept your help, but it sounds more like a cry for help, than a real help. And that’s because you are assuming things as every one.

REDcine should normally have three options A) REC709 Linear, B) Cineon LOG, C) whatever RED R&D likes. The last one should come with substantial documentation along with proper LUTs in order to be useful.

I still can’t understand why is so difficult to have a proper Cineon LOG.

A fast workaround could be a curve file that can be loaded to REDcine (at color tab) designed in such a way to fix REDlog in order to put the values in the correct places.

In reality the REDcine wouldn’t need any adjustments if it was used to export DPX Cineon Log, the big red button would be the only adjustment, since Cineon Log has all the headroom to accommodate RED images, actually, I thing it has so much headroom that we can put one and a half RED images!

 

[M Most]

4. The best log format is REDLOG it takes into account all the subtle sensor sensitivity issues and it was the first LOG file from the RED team. It works really well - except you need to make a LUT for it. If you don't make and use a REDLOG LUT and use some other LUT , it will no doubt look wrong.

Without documentation (and as far as I know, there still hasn't been any) that's almost impossible to do, at least to do accurately. Sure, you can do a blanket color correction - i.e., take a bunch of shots, pull up the blacks, pull down the gain, adjust gamma to taste, and do it all while looking through either a print preview (if you're correcting for film) or a log to lin (if you're correcting for video) view LUT - but that's hardly scientific.

It can give pretty good results, though.

 

[Jeff Brue]

In scratch they actually have LUTs that show the Red Log curve, those are the LUTs that we used to ccreate our own curves in nucoda.

 

[Evangelos Achillopoulos]

Our fevorite tool...

Our fevorite tool...

MMost, do you know what the favorite tool of a Greek car engineer is?

The hummer!

Of coarse and I can do that “blanket color”… I do it all the time… but as the car, when you hummer it all the time, at the end it will break!

We using the most revolutionary Digital Cinema camera in the world and I still have to use my hummer???!!! :blink:

Sorry for the sarcasms, but it’s the way I feel. We really need same “science” to be added to RED software…:help:

 

[Mike Seymour]

You say I am assuming, and of course to a point you are right but I have done a lot in this area - Graeme and I spend 15 - 20 mins discussing this our my podcast red center ar fxguide.com - so it is not just guess work on my behalf. Also I got one of the first cameras #22 so I have been doing it since Sept, plus I have some experience professional and I have a post background. ... but what I hear is you want RED to say this not me. That's fine with the misinformation out there I can understand that

A few follow up points - perhaps helpful - I hope so.

The data is 12 bit linear from the sensor not 10 bit linear.

You missunderstand the nature of the process. PD685 is an export conversion to the non red domain. You need to decide what to map into that PD 685 space. I hear your point - but the way it works is a two stage process. You'd like all the data mapped into PD685 - not just the section of the histogram you are dealing with. Valid request not how it works. it is a conversion not an equivalent.

Redlog is published we have built LUTs so have others. There is no black magic or secret club. it's a 1D LUT. You use sarcasm when asking about the LUT so I guess you are upset, but have you spoken to RED to ask for the RedLut info? Do you own a camera? I have found the team very helpful.

I have also been doing this for 20 years but I think the process of Cineon log files, unity, 3D profiling LUTs, calibration and targeting is just that complex. But my point is a linear output from red is just as valid. You talk of video REC709 but yes Rec 709 is HD based but my point is all the data is in that file, you may have already known this but some assume a Log file will be better, this is what I was flagging.

the PD685 is not a rough approximation so much as just inferior technically to REDLOG. Would this matter to most people perhaps not but we are speaking technically here.

So in terms of what you shot - adjust before conversion and yes you can convert the full range of the sensor to Log, or keep it linear. But the Camera does not work LOG - no sensor camera does as you know, and once you see it as a conversion two stage approach it makes sense. Why does it need to be two stages? Well at stage 1 it is RAW, no matrixing, no whitebalance, no noise reducing, sharpening, etc that is all normally done BEFORE you see a signal on a Sony, Panasonic, or Panavision camera. Digital cinema is not a LOG format - it is based on linear sensors -the only reason people use LOG is to save disk space. 40% correct - except .r3d files are 3.3% of uncompressed roughly, so universally a better saving. (I assume a .r3d is about 1/30th of an uncompressed 4K tiff)

You are correct tiff is big and not a good storage format.

And with respect - they are not being arrogant. Heck all the redline, red alert, and red Cine software is FREE. I am not being a fan boy here but come on. If you want a major professional tool for your serious pipeline buy a Scratch. The level of software support from Red is stunningly high. You are complaining about freeware. You are complaining about a FREE ap given away to help people out as if you had spent $$$ on it and it did not work correctly?

I get your a bit upset - and perhaps at me too... I hope not, as I am a free resource too

Anyway the big red button would again miss the workflow of processing RAW files and then converting the data you like to non-red RAW format.

If red output its files from the camera as some RED image format - like a tiff - but with image data and all processing locked in - a simple conversion "give me all of that in log" program like TGA to Tiff or Jpeg to PNG makes sense. But this is a mega layered photoshop document and while it has a preview (like a PSD) - to get the most out of it you need to get into the file and make some decisions. I can do a simple convert a PSD doc to a flattened image but if I do I should not be upset I lost alphas or other adjustment options. To use an analogy. If I want complete control I open in PSD - make alphas - decide which hidden layers to delete and finally export a file that works for me, knowing a flatten version of this PSD will never have the flexibility my PSD file had. I hope that analogy makes sense.

Once again I seriously offer any further advice if it is helpful, sorry if it is not, my aussie accent may get in the way.I am only trying to help honest.

Mike

Mike thanks for your explanation, but allow me to clear up few things…

I thing that the answer to my post, has to came from the really responsible people of RED, that are the makers of the tools that we use, in order to make the most out of their cameras.

So I can accept your POV, but you are ASSUMING things as I…

<snip>


The RAW data on disk are not clipped no matter what I do “In post” so because I had wrong mapping of code values in the PDlog685 I tried to lift the white by changing in post ASA… but apparently this is where I realized that REDCine doesn’t have a proper Cineon Log output…



Mapping the 10 bit linear video data to a Log space will result to a weak Log histogram similar to what is happening when we all trying to do this workaround with an F900R i.e.. A Varicam used in Filmrec mode, with a AJ-HD1400 VTR as a player, setup with Cineon850 conversion curve (in the menu item 693) will give a heavy histogram similar to a negative scanned and with code values that are reaching 850. The F900 or any REC709 camera with lin to log conversion is resulting to a WWWW looking Log histogram. Never the less the 10bit log is at least 14bit linear. And by any means 10bit linear can’t carry 12bit linear info…

Where can we find that LUT? Do we have to guess it? Or I have to reverse engineer the REDLog?

I believe, unable… unwilling??? So if it’s not Cineon what it is? It’s a new invention? The film out is NOT a simple job! Rough approximations are just non professional.

I don’t want to have a specific LUT for my set up. I just want to have the 1D LUT that converts the REDLog to a proper Cineon Log. I know that manufactures that care they do give a LUT to convert to Cineon as Thompson did with Viper, as Panasonic is doing for years with the Gamma Box or the AJ-HD1400, 1700 the Panasonic monitors etc. Sony was following the same arrogant behaviour like RED is doing. Sorry that I’m so aggressive but I thing that a Digital Cinema camera should be following the typical Cineon Log workflow and not a TV workflow that REC 709 is.

Also their is no such thing like "Complex LOG pipeline", I just have a common Cineon Log workflow, as many of us, that working with film the last 20 years...



No am not asking for more latitude, I just want what I have shot (and its on the RAW file) to be also on the output file, and that is possible with either Tiff 16bit or DPX 10bit Cineon Log which is an industry standard. I don’t prefer Tiff because I need 40% more disk space.



I never ask for 14 stops from the camera… (probably in my dreams) I just said that Cineon Log its being designed to accommodate 14 stops. So the 7 - 8 stops of RED can fit the Cineon Log space easily.



If its so, why I can have it i.e. from Varicam with a click of a button? Varicam it’s not a film camera either… And when am asking “full Cineon Log space” I mean not limited to 685cv to be able to reach 800cv, 900cv whatever is the max scene brightness of the camera. I don’t expect to get film numbers like 950cv or more…

Mike I do accept your help, but it sounds more like a cry for help, than a real help. And that’s because you are assuming things as every one.

REDcine should normally have three options A) REC709 Linear, B) Cineon LOG, C) whatever RED R&D likes. The last one should come with substantial documentation along with proper LUTs in order to be useful.

I still can’t understand why is so difficult to have a proper Cineon LOG.

A fast workaround could be a curve file that can be loaded to REDcine (at color tab) designed in such a way to fix REDlog in order to put the values in the correct places.

In reality the REDcine wouldn’t need any adjustments if it was used to export DPX Cineon Log, the big red button would be the only adjustment, since Cineon Log has all the headroom to accommodate RED images, actually, I thing it has so much headroom that we can put one and a half RED images!

 

[Evangelos Achillopoulos]

I didn't knew that we have to pay 100K$ (scratch) to have the magic LUT's...

I didn't knew that we have to pay 100K$ (scratch) to have the magic LUT's...

In scratch they actually have LUTs that show the Red Log curve, those are the LUTs that we used to ccreate our own curves in nucoda.

Can someone put us, the poor guys of post, in the game... can someone give us these magic LUT's for god sake!!! It's :cold: out there...

 

[Cüneyt Kaya]

Can someone put us, the poor guys of post, in the game... can someone give us these magic LUT's for god sake!!! It's :cold: out there...

hey evangelos, the LUTs from scratch are here

http://www.red.com/support

rednode

and this is from the installation nodes


3) Copy the RED Luts folder into the \LUT directory of your SCRATCH installation. By
default, this directory is located at: C:\Program Files\Assimilate\Settings\LUT

hope this helps you/ and then me...

 

[Mike Seymour]

hey evangelos, the LUTs from scratch are here

http://www.red.com/support

rednode

and this is from the installation nodes


3) Copy the RED Luts folder into the \LUT directory of your SCRATCH installation. By
default, this directory is located at: C:\Program Files\Assimilate\Settings\LUT

hope this helps you/ and then me...

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.

 

[Cüneyt Kaya]

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.

what does your post has to do with my post?

I never said that scratchcine is 100 k

 

[Evangelos Achillopoulos]

Yes Mike I’m little bit upset… It’s because I have some simple expectations from a camera that’s so revolutionary and I realize that’s not like that.

Can you please point me were is the 1D LUT that you mention on your web site in order to try and make a workaround for REDcine...

As to if I own a RED camera... I do serve a spec spot ad that uses three RED’s… If I didn’t have the fire inside me to make the best out of it, would I ever bother to write 10 pages of text in this forum just to find a solution?

Is it just me that will be benefited from my work or RED will have a better chance against the film hardliners that didn’t want RED to succeed in that Greek project?

I didn’t knew that I have to buy another system that’s 100K$ like scratch in order to do what am doing all the time. I have an established setup and I don’t want to change it for a stupid 1D LUT… And I don’t have the time to do it… in two days I have to deliver…

If I don’t have another way, I will use (again) the hummer! with less quality but I will save my ass...

I don't thing that RED team should be proud about that if I will be forced to do it.

 

[Evangelos Achillopoulos]

Thanks Kaya, I will try it.

My Apple Color setup has cost already 15K$ I don't want to buy anything else...

And especially I don't like to be forced to do so...

 

[Cüneyt Kaya]

Thanks Kaya, I will try it.

My Apple Color setup has cost already 15K$ I don't want to buy anything else...

And especially I don't like to be forced to do so...

build 16, sdk release....i hope in 6 months all of this stress will belong to the past.

 

[Mike Seymour]

what does your post has to do with my post?

I never said that scratchcine is 100 k

No sorry an earlier post not by you had the heading
"I didn't knew that we have to pay 100K$ (scratch) to have the magic LUT's..."And then when I saw you post on red node / scratch I just hit reply. I did not mean to imply you said that sorry

Mike

 

[Mike Seymour]

if you still need the spec for the LUT to build one email me at mikes @ fxguide.com and I will happily send it to you.

You dont need to buy a Scratch - it is just a great post tool for serious post.

Sorry you are still up set and that we have not been able to help you more

mike

Yes Mike I’m little bit upset… It’s because I have some simple expectations from a camera that’s so revolutionary and I realize that’s not like that.

Can you please point me were is the 1D LUT that you mention on your web site in order to try and make a workaround for REDcine...

As to if I own a RED camera... I do serve a spec spot ad that uses three RED’s… If I didn’t have the fire inside me to make the best out of it, would I ever bother to write 10 pages of text in this forum just to find a solution?

Is it just me that will be benefited from my work or RED will have a better chance against the film hardliners that didn’t want RED to succeed in that Greek project?

I didn’t knew that I have to buy another system that’s 100K$ like scratch in order to do what am doing all the time. I have an established setup and I don’t want to change it for a stupid 1D LUT… And I don’t have the time to do it… in two days I have to deliver…

If I don’t have another way, I will use (again) the hummer! with less quality but I will save my ass...

I don't thing that RED team should be proud about that if I will be forced to do it.

 

[Steve Sherrick]

Evangelos, if Mike's help is not what you are after, I encourage you to call RED directly then. I actually think he is being more than reasonable here, even offering to help you with the LUTs. Quite honestly, it seems like you are just pissed off at RED and taking it out on Mike, who was only trying to help.

I would also caution against taking on projects without having all of this figured out beforehand. I'm not sure if that is the case with you and your project, but I got the impression that you went in with assumptions and now that they have not met your expectations, you are in a jam.

Not trying to give you a hard time at all, but when I see people offering help and then getting no love back, it seems as though it could be handled a little better. We've all got the same goal here - workflows that fit our needs. You don't have to agree with someone's take on it, but at least give them proper respect.

But otherwise, it's a good thread and useful information.

 

[jimhare]

I agree, Mike is at the forefront of this stuff and spent more time understanding it than anyone. He has done nothing but calmly try to help here.

If he believes there is a resolution, I believe him.

Respect where respect is due.

 

[Evangelos Achillopoulos]

Mike and Steve.

I do accept your honest help and I do respect the forum, am not upset with you guys, I just don’t believe the size of irresponsibility that manufactures have. They really don’t test anything, they waiting us to find all the bugs and then wait until they fix it and in the meantime we have to deal with a pile of problems…

Before I would even thing to put something in the market I’m always killing it in QA they simple don’t care…

What I need (what all of us need until REDcine produces a proper Cineon export) is a 1D LUT that takes the x value of the REDLog and replaces it with the y value, and the result is a proper Cineon file.

An alternative could be:

Use REDLog in REDCine and put a custom curve in the curve function in REDcine. If we create a curve that is repositions the REDlog output to the Cineon code values we can have a very good workaround that can be easily distributed among users.

Of coarse I would expect Graeme to lead that effort since he knows the inside out of REDLog and RedCine and don’t expect us to reverse engineer the RedCine Curve as well as the REDLog LUT for scratch…

I don’t want to call RED since am not an owner as first reason and as a second I thing that the public domain is more appropriate in order to share and distribute solutions fast to all the community.

Sorry for the frustration but am getting exhausted of that debugging process as users has to solve everything… I just wont a more active reaction from the manufacture.