Welcome to our community

Be a part of something great, join today!

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

Is RedCine crippled on purpose?

Redcine may be made redundant in the very near future for professional users - and that's a good thing - for an industry to support the camera there has to be a dollar in it for everybody - and no one makes a dollar from free software.

I agree in as much as I think thats the fastest way to make Red footage easy to deal with, get it out there and supported (which costs), but.. Firstly, lots of people could make a dollar using free software, its called freeware, and some of it is seriously useful. Second, I couldn`t care less who makes a dollar except Red in this whole adventure, right now. That logic assumes that if all the big software packages, and every studio in the movie industry refused to support R3D files, people wouldn`t keep buying the camera anyway, maybe just more independant film makers and artists than big players, using RC and crimson, baking out dpx files or tiffs, and getting by any how they can to get those beautiful images, which I think they will, and are doing already, and are glad they did, which is important.
I`ll be creating freeware tools to do most things I need, including colour grading if I have to, because frankly, I`ve got debt now. I`d rather concentrate on artistic matters at hand, but unless Assimilate or someone decide to seriously increase their revenue, and much faster than their profits, I`ll be buying land before scratch etc.. I need some full featured, software only, non-"realtime/compromised quality", OEM, retail version I think, at slightly less than Soft Image XSI prices to create demand in my mind.
I think Reds future involves profit and sales regardless of industry uptake. I say this because I know I can`t be the only one who was just wondering who`d be clever enough to make a decent affordable digital cine camera that takes pictures like a totally afforadable DSLR, or at least HD with some decent dynamic range and a picture not made of lego. Thankfully a billionaire photographer entrepreneur crossed the line first, and five years faster than I`d personally expected, and I`d say has an eighteen month jump on the competition right now (except silicon imaging and cineform..), but a bit of free software that gets periodically maintained and does some of the basics, I don`t think is going to hurt anything or anyone, so thats a good thing too surely
 
Got to say though "not making it easy" has kind of paid of for me. Of course I'd rather the process be a strait forward EDL import from FCP to RC. But a few producers have contacted me about using R1. Since they are used to the good ol days of film transfer and tape capture they can't get their heads around the work flow. So I turn in to post format converter, something I like to reflect in an invoice then after.

Who ever thought that being a geek would pay off! Keeping the work flow complicated and cryptic is great, keep up the good work R team!

Thats funny. keep up the obfuscation :usd:
 
...
We would all agree that the optimal RED workflow for best image quality is:

1) Shoot
2) Edit
3) Transcode the cut to DPX sequence
4) color grade the DPX sequence

...

I disagree on the "best image quality" bit. I don`t have my Red yet, and I don`t do DPX 10bit log processing. Fortunately, neither does the R1 sensor (12bit linear), so I`ll be exporting 16bit TIFFs, instead of throwing away 75% of my code values.
Even if 10bit log captures the most important parts of the signal, it doesn`t capture as much, period. Converting 4096 code values->1024 code values, is only necessary if the 50mb TIFFs are too big for you to handle, and for me they`re not, as it will give me more to grade with later, and I won`t have to convert it back from Log format first. That said, can`t the DPX format handle 12bit linear values according to the DPX specifications?
 
I think Miltos makes a great point. The prospect of Redcine being able to transcode FCP xml files would seem a relatively straightforward bit of coding - and make the current workflow far more palatable.

However, my instincts indicate that Red is aware that Apple is preparing to allow either FCP or Color to handle R3D files in the near future. As such, if Red provided an inclusive solution for FCP2, they may deter potential Apple customers from paying for the upgrade - no need to become an indirect competitor to Apple when you want to keep in their good books. I believe it's a win/win for Red/Apple. Red provided a 100k+ camera for 20k. Back in the day, Apple provided FCP for a fraction of the price of Avid. What's good for these two Mavericks is good for me... I'll just have to wait a bit longer.

Nick.
 
Ok - if you own a camera and need better tools to shoot with it I feel for you wanting better solutions - and upgrading RedCine and paying for that upgrade would seem like a good solution - that's effectively what Scratch Cine is (it's a hell of an upgrade - with an accompanying price change - but that's what it is) - but it's not like the camera, workflow and footage to test such things with haven't been posted since before anyone but the first 50 took delivery.

If you brought the camera with only the tools that were available at that time then you knew that you were going to be waiting an indeterminate amount of time before more post solutions were available - and you also knew that Redcine was available as is.

I don't own RedONE, I don't plan on owning RedONE - I'm not a cameraman or a cinematographer and don't operate a self sufficient production studio.

I do work in production and post production and have worked with Red Footage and also have seen the various tools to make it work executed by various people and my take on is that at it's price it's an amazing tool that doesn't yet have a reliable very cheap post workflow, has a couple of not so reliable but very cheap workflows (RedCine combined with RedLine - RedAlert) or a ubiquitous post workflow.

Not having a cheap post workflow means you can operate as if it was film.

Not having a reliable but very cheap workflow makes it different from video, but for most of those types of job I don't see the issue with just using video (I'm a renter - not a buyer, right tool for the job kind of guy).

Having a not entirely reliable but fairly cheap workflow (Apple plus Crimson plus RedAlert/Redline) that produces film quality output is phenomenal, and having an incredibly cheap workflow that works not entirely reliable on some systems (PC plus Crimson plus Redcine) is also incredible.

Crimson is not expensive, Redcine is free and I really don't see the problem with needing a third party solution if it works.

And Ronx if you have the time and expertise to make your free software then decide to give it away to other people then that's your generosity it's not directly making you money but it might be good marketing. Sure lots of people make money USING freeware, but no one makes money from the making of freeware (just like they don't make money from self promotion - it's a gamble that may pay off but on it's own giving away software is like giving away anything else - it's an act of goodwill.)
 
It's quite possible there's all sorts going on behind the scenes, deliberately or through focus being directed elsewhere. Maybe Red keep Redcine dumb to keep others happy. I don't care. I'm just delighted that Crimson gives us a workaround right now, for the price of a night on the town. We were never going to buy Scratch, but we wanted to do post in-house. Without Crimson, we'd have had to hire a lot of interns to dial in the numbers manually. Bottom line, we can do what we want for an extra $200. No complaints.
 
Just because you're paranoid doesn't mean they're not after you! And yes, drinking will help.

I deleted my original post, because I reread it, and... it was some patronizing shit. :)

Lucas
------
ASSIMILATE, inc.
LA, CA, USA
 
Just because you're paranoid doesn't mean they're not after you! And yes, drinking will help.

I deleted my original post, because I reread it, and... it was some patronizing shit. :)

Lucas
------
ASSIMILATE, inc.
LA, CA, USA

shit, sorry, I need to take my post down also, do you know how? I`m not after you, your daughter maybe! Marujuana doesn`t help either, but the music sounds better..except there is none playing :shifty:
 
I don’t think RedCine is purposely crippled in comparison to Scratch but when it comes to PC platform the video card support on RedCine is crippled. I just tested two video cards with RedCine 106 on two different computers, one equipped with NVIDIA Quadro 3600M the second with NVIDIA 8800M.

I see the RedCine is still using the old video card support and memory management as the old Scratch 3.2x Where Scratch is 3 revisions ahead.

The end result is, I can’t use RedCine 106 on PC platform and I am trying it on two different well recognized brands of computers and two different NVIDIA cards.

I am back to Mac box to convert all RED footage to TIFFs and then the freedom of choice.
I am doing it since the day I got my camera and it looks like nothing has changed in the SCRATCH-REDCINE land.




I run Scratch and then RedCine 106 with the same configuration, the same OS, video card, hardware, etc.

Here is log from RedCine
21:18:56.03 INFO : Initialize Player Session..
21:19:57.17 INFO : Update Project Media registry
: Updated/saved 0 clips (0.0031 Sec.)
: PB: 'ImgProcess', Create a 4096x2048 Pixel Buffer..
21:19:58.24 ERROR: GFX PB(1): Unable to create pixel buffer : ''
21:19:58.24 ERROR: CG: Failed to setup a 4096x2048 pixel buffer..
: PB: 'ImgTexture', Create a 1024x512 Pixel Buffer..
: PB: Ready..
21:19:59.73 WARN : TX Display texture failed(2)
: Image: ' 4096x2048 RGB, 10 bit (Lin) '
21:19:59.73 WARN : TX Display texture failed(1)
: Image: ' 4096x2048 RGB, 10 bit (Lin) '
21:37:14.88 WARN : TX Display texture failed..
21:37:14.88 ERROR: Render: Failed to allocate source texture(1)
: Average time per frame 1.208 (0.83 FPS)

Here is log from SCRATCH
11:01:17.17 INFO : Initialize Player Session..
11:01:17.17 INFO : Setup Shot Player, Session 2
: PB: 'ImgTexture', Create a 4096x2048 Pixel Buffer..
11:01:21.05 INFO : Terminate Player..
11:01:21.06 INFO : Player Session ended..
: Session ended
 
I don’t think RedCine is purposely crippled in comparison to Scratch but when it comes to PC platform the video card support on RedCine is crippled. I just tested two video cards with RedCine 106 on two different computers, one equipped with NVIDIA Quadro 3600M the second with NVIDIA 8800M.

I see the RedCine is still using the old video card support and memory management as the old Scratch 3.2x Where Scratch is 3 revisions ahead.
Jim is getting leftovers from the Scratch table.

Andrew,

Leave the inflammatory comments out of this and let's try to get at the heart of your problem.

First of all - are you running this in XP 32, or compatibility mode from Vista64? Because "compatibility mode" isn't. That's why we tell people to run on XP32 or Server2003... and that's it. A quick Google search will show you looooooots of programs that don't even come close to running well in compatibility mode. So unless these results are from XP32, they aren't valid.

Second, if you can (offlist) send me your most recent logfiles from both REDCINE and SCRATCH, I can forward appropriately and let the REDCINE team take a look.

Best,

Lucas
------
ASSIMILATE, inc.
LA, CA, USA
 
Luki, sorry I was upset after hours of testing with 106 and such disappointment at the end.
As you see it is not a question of being able to run RedCine 106 on PC, YES I can find PC that will run RC106, but question of seeing SCRATCH running perfect on most of new and fast PCs and RC106 not running.

>First of all - are you running this in XP 32, or compatibility mode from Vista64?
I did try RC106 on 4 different setups, from XP32 to Vista32 and 64.

SCRATCH is running fine.
RC106 is not fine.

SCRATCH 3.2 is not fine on Vista 32 and 8800M
SCRATCH 4.0 is fine on XP 32 XP 64 Vista 32 Vista 64

Whatever you guys did for Scratch 4.0 is just right.
Should I PM my log to you?
 
>First of all - are you running this in XP 32, or compatibility mode from Vista64?
I did try RC106 on 4 different setups, from XP32 to Vista32 and 64.

Ok... Just saying - the logfiles from anything other than XP32 will probably not be very useful.

Send the logfiles from Redcine and SCRATCH to my email - lucas (at) assimilateinc (dot) com.

Tx,

Lucas
 
I have 2 Reds and only use PCs. I typically record 1 hour with the 2 cameras synced and then process the .r3d files to 1920 X 1080 for editing and Blu-ray and DVD output. It takes about 1 week to process the 2 files. What happens is that RC starts out doing about 1 frame per second and them gradually slows down untill it is running about 3 seconds per frame.
My question is: Are any of you having this happen?

Dave

Dave,

That sounds about right. I was outputting uncompressed QT files on my Windows machine, then recompressing them to the Matrox codec for realtime editing. 1 to 2 frames per second at first, then slower as it went along. Fortunately, I was processing groups of files and could restart from time to time. Sounds like you're not able to do that.

At NAB, Cineform was converting .R3D files to Cineform RAW at a rate of about 12 frames per second. Then they were editing and making color adjustments in realtime on a 64 bit XP machine with 4GB of RAM and 8 cores. Not an inexpensive machine, but not out of reach, either.

Can't wait for that Cineform solution!

EDIT: I understand that RedCine is getting NOS, or a supercharger, or a turbo, or something. It should be faster in the near future, which would also be very good!

-Thor
 
Back
Top