Welcome to our community

Be a part of something great, join today!

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 :)

RELEASED: Beta RED ALERT! v20.1.2

Brent Carter

Brent Carter

REDUSER.NET
Joined
Aug 22, 2007
Messages
4,992
Reaction score
5
Points
0
Location
Irvine CA
Available on www.red.com/support .

Changes since v20.0.1:

* Resolves bug for RED ALERT!, REDline, and REDrushes so color is consistent across RED ALERT! to SDK to RED ONE.

* Other minor bug fixes.

Thanks, BC
 
sweet......
 
Hi Brent,
Love what your doing, but we have a problem that you may be able to answer.
We use the quicktime proxies alot. So much so that we master from them almost every second job.

The OLD red alert was good because when we made new quick time proxies, what we saw in the RED ALERT viewer we got back as new quick time proxies. Nice and easy.

With the new RED ALERT, the proxies we cannot match and they come out all sorts of crazy white balances.
How can we get back what we once had with the last RED ALERT.
Is there a way of making new quicktime proxies that match the RED ALERT viewer.

This is very important for our work flow. Quick time proxies are king, even better if we can tweak them in RED ALERT and get back what we see.

thanks Brent, Look forward to your reply.
 
QuickTimes

QuickTimes

Hi Big T, as Laco commented the colors displayed by QuickTime reference files won't match to Build 20 RA!

- there needs to be an update to the RED QuickTime Codec first.

So two options. Use a previous build of RA! or render out standalone QuickTime movies via RA!.
 
Stuart English said:
Hi Big T, as Laco commented the colors displayed by QuickTime reference files won't match to Build 20 RA!

- there needs to be an update to the RED QuickTime Codec first.

So two options. Use a previous build of RA! or render out standalone QuickTime movies via RA!.
Click to expand...

Thanks mate,

going back to old RA now.

cool
 
Simon Blackledge said:
I know it's been asked for a thousand times.

At any point can we get curves following over into the proxies also..?

si
Click to expand...


Yes. A number of things are now coming together on the code side to support that. Most likely that will happen in August when the core work is finished.
 
Asa and White balance dead !

Asa and White balance dead !

Hi, today in the midle of shooting we cant change asa and white balance corrections, we try everything and finaly reseting the USER settings the camera works fine, but after 20 minutes the problem goes back. This is the firts shooting with Build 20 (v20.0.0), Is now available a new build 20.0.1 ?.
Anybody experience the same problem ?

Thanks
 
Jose Luis Guridi said:
Hi, today in the midle of shooting we cant change asa and white balance corrections, we try everything and finaly reseting the USER settings the camera works fine, but after 20 minutes the problem goes back. This is the firts shooting with Build 20 (v20.0.0), Is now available a new build 20.0.1 ?.
Anybody experience the same problem ?

Thanks
Click to expand...

Try restoring to factory defaults and then reinstalling the firmware.
 
Had to go back to version 3 today. We had severe colour issues with a job we just did. One facilty did the dailies transfer to DNx60 quicktimes for the offline so that is what the client expected rushes to look like when it came to us. As we had not seen the material prior to our debayer we thought the footage looked a bit odd and very dark. We transfered just the cut using Monkey Extract and latest Red Alert/Redline build to DPX. In the suite we noticed a huge difference in colour balance between online and offline files. I matched the settings the company had used in offline but could not reproduce the same results. We had to do a full pregrade to get anywhere near. The client was not at all happy making out that this was something we had done wrong.

As we have finished in excess of 30 red jobs of the last 18 months I assure them we did everything correct and followed the same procedure we always do. To work out what was wrong I back tracked and looked at the rushes on another cluster we had not upgraded to build 20. Low and behold everything looked as it should here.

I recommend that people hold off build 20 until this issue is resolved.
 
Just found out from another post, that I have to re white balance all clips prior to build 20 before debayering in build 20. Not ideal but a solution I suppose. Is there no plan to have this automated?
 
Build 20, is after all in BETA. So you should use accordingly. You need to test prior to shooting for clients, check everything, test under the conditions you will be shooting.

So far we know there are bugs in Build 20, we've known from the first week of it release, so please spare yourself grief, and only use 20 in situations wher it's works properly, or downgrade to Build 17.

If you rent a camera from any pro house you get Build 17, not 20, not until it's officially released.

Beta is for testing, trying new things, finding out what it does, and does not do, and reporting to the mothership so they can make corrections and improvements.

I've been beta testing software for years will digital still, and in closely watched high dollar gigs, I'd never use the beta, too risky, I use what I know works, and wait.

So don't forget "This is a TEST".
 
Deanan said:
Yes. A number of things are now coming together on the code side to support that. Most likely that will happen in August when the core work is finished.
Click to expand...

Thats great news! Thanks D.


s
 
Von Thomas said:
Build 20, is after all in BETA. So you should use accordingly. You need to test prior to shooting for clients, check everything, test under the conditions you will be shooting.

So far we know there are bugs in Build 20, we've known from the first week of it release, so please spare yourself grief, and only use 20 in situations wher it's works properly, or downgrade to Build 17.

If you rent a camera from any pro house you get Build 17, not 20, not until it's officially released.

Beta is for testing, trying new things, finding out what it does, and does not do, and reporting to the mothership so they can make corrections and improvements.

I've been beta testing software for years will digital still, and in closely watched high dollar gigs, I'd never use the beta, too risky, I use what I know works, and wait.

So don't forget "This is a TEST".
Click to expand...


All Reds debayer and post software is forever in Beta though so what choice do you get. We did not shoot the material either only posting the stuff. It should be made more clear that if you are updating RedAlert/Redline to build 20 you must re-white balance all material shot on previous builds of camera. From the looks of things on the forum I am not the only one who has fallen in to this problem.
 
Anybody know when the new colour science will be in RedLine as we only use RedLine for rendering as we can send it too our render farm.
 
You must log in or register to reply here.
Back
Top