5DtoRGB new beta now FREE and UNLIMITED!

[Postmaster]

I don´t want to be on your nerves Thomas, but
a PC version would be soooo much appreciated.

Thank´s, Frank

 

[Thomas Worth]

Thomas could you confirm that my G5 (powerPC) wont run your software ?

G5 may be possible. I know the G5 is 64 bit capable, and that's good because some of the modules in 5DtoRGB require it (for now, anyway). I have an old Xserve G5 somewhere that I could test this on. Are you running Mac OS X 10.5 on the G5?

I don´t want to be on your nerves Thomas, but
a PC version would be soooo much appreciated.

It's coming. It will likely output uncompressed and DNxHD QuickTime files (in addition to DPX, of course). I have a command-line Windows version working, but it still needs a lot of work. And a GUI ;-)

 

[morgan_moore]

Means nothing to me..

Model Name: Power Mac G5
Model Identifier: PowerMac7,3
Processor Name: PowerPC G5 (2.2)
Processor Speed: 2 GHz
Number Of CPUs: 2
L2 Cache (per CPU): 512 KB
Memory: 6 GB
Bus Speed: 1 GHz
Boot ROM Version: 5.1.8f8
Hardware UUID: 00000000-0000-1000-8000-000D932F7C9E


-----

System Version: Mac OS X 10.5.8 (9L31a)
Kernel Version: Darwin 9.8.0
Boot Volume: Macintosh HD
Boot Mode: Normal

Just comes up with a not supported icon

S

 

[Noel Evans]

This looks right. 5DtoRGB's output files have less contrast because they have not undergone pa gamma correction. The YCbCr data only goes through two steps: 1.) a chroma upsample, and 2.) a YCbCr to RBG conversion. This is the minimum amount of processing needed to get a usable image from the Canon files. Everything else is left up to the colorist, as 5DtoRGB is designed to generate files optimized for color correction. Gamma correction and other color operations can be performed during color correction just as easily, and I'd rather leave those decisions up to the colorist.

Good call. Will get on board and give it a run. Gamma lift can be a real problem on conversion adding noise. This looks like the right way to go.

 

[stew75]

Thomas,
I don't mean to take away from your program because I think its pretty awesome, but I have a question. I've been using Apple Compressor to transcode all of my H.264 files to ProRes LT and haven't noticed any problems. I looked on your website and you mention everything but Compressor when talking about your software. Should I assume that means Compressor is equal to your product when doing a ProRes LT conversions?

Also, I've been reading that anything above a ProRes LT convert is just kind of a waste because H.264's quality isn't higher then ProRes LT. I could be wrong, but that's just what I was reading in a few threads. So my understanding taking a H.264 file and converting it to a ProRes 444 file would be like taking and SD video and converting it to 4k. Sure it would be 4k, but since it was captured at SD it will never be better then that.

Again I'm just asking because I'm not really sure and would love to know the correct answer. I dig your product and the only reason I'm not wanting to use it more is because I want to do a batch convert and can't sit through a days worth of takes and keep choosing one file at a time. I read in your release notes you can sort of do it in a Terminal, but it seems like alot of work if I can just use Compressor and get the same outcome.

Good work though and I really do dig your product and look forward to its evolution.

 

[Thomas Worth]

Thomas,
I don't mean to take away from your program because I think its pretty awesome, but I have a question. I've been using Apple Compressor to transcode all of my H.264 files to ProRes LT and haven't noticed any problems. I looked on your website and you mention everything but Compressor when talking about your software. Should I assume that means Compressor is equal to your product when doing a ProRes LT conversions?

No. Compressor uses the same decoder used by the Canon E1 plugin, MPEG Streamclip, Final Cut Pro, and almost everything else on the Mac. Therefore, it's subject to the same quality problems.

Also, I've been reading that anything above a ProRes LT convert is just kind of a waste because H.264's quality isn't higher then ProRes LT. I could be wrong, but that's just what I was reading in a few threads.

I would only use these lower bitrate codecs is if I knew I was going to downconvert the footage to SD or for web use at some point. Otherwise, use a higher bitrate ProRes variant.

the only reason I'm not wanting to use it more is because I want to do a batch convert and can't sit through a days worth of takes and keep choosing one file at a time. I read in your release notes you can sort of do it in a Terminal, but it seems like alot of work if I can just use Compressor and get the same outcome.

Batch processing is very important feature. Very important. I think you can see where I'm going with this. ;-)

 

[Noel Evans]

^+1 to the batch processing, but it looks like youre already on that.

But there is another feature which would make this really kick ass would be the ability to go through clips and set in and outs before conversion - then add to batch list.

Couple of comparatives.

Original clip size: 100.7MB

After Prores 4444 conversion with 5dtorgb: 571.5 MB

After Prores 4444 100% quality conversion with mpeg streamclip: 404.5MB

Original clip total frames: 423

Time to convert to prores 4444 with 5dtorgb: 1min 45 sec.

Time to convert to prores 4444 with mpegstreamclip: 0min 16 sec

Conversion system info: Mac pro 4,1 using Caldigit HDelement on raid 5 - Backmagic Disk speed check test : Disk read speed - 350 MB/s - Disk Write Speed - 290MB/s

 

[Spartacus]

Couple of comparatives.

Original clip size: 100.7MB

After Prores 4444 conversion with 5dtorgb: 571.5 MB

After Prores 4444 100% quality conversion with mpeg streamclip: 404.5MB

Original clip total frames: 423

Time to convert to prores 4444 with 5dtorgb: 1min 45 sec.

Time to convert to prores 4444 with mpegstreamclip: 0min 16 sec

Wow. There´s obviously a price to pay when it comes to getting the most out of the Canons...:shocked:

 

[Noel Evans]

Keep in mind though that this is Prores 4444. Most people wouldnt ever take it past 4:2:2.

Did some tests this morning and heres what else I can deduce.

I used a 5dtorgb clip converted to REC.709 @ 1.8 gamma and the mpegstreamclip version.

Imported to FCP, sent to color, applied same grade to both clips. Here's what I saw.

On my Panasonic PF12 using HD-SDI @ rec.709, the mpegstreamclip version looks crushed. Seems Ive lost most of the dynamic range I had to start with. Keep in mind that I applied the same grade to both clips. The grade was done on the 5dtorgb version and then copied. You could do a little more to protect your clip if your just grading for the mpegstreamlip version. The 5dtorgb version was superb.

Back in FCP I zoomed in to 800% on both. What I saw then was the 5Dtorgb converted clip was cleaner and the colors betweeen objects were smoother.

So to surmise I would say that when doing anything like greenscreen or heavy vfx, 5dtorgb is your friend. I dont need to surmise that 5dtorgb conversion is better for grading. How much better? Will you be zooming your clip 400-800%? Silly question really. But the more grading you do the benefits are exponential.

I would add that those using prores 4:2:2 iterations would most likely see a smaller variance.

Just want to add a small caveat. I shoot a superflat setting, and always intend to do a 4444 conversion and treat it like RAW (well as close as you can). My system rips through it like butter. I wouldnt recommend this workflow if youre on a slower system with slower drive speeds. A standard internal sata drive on a mac will yield a read speed of about 100-120 mbps. My raid 5 does 350.

To conclude, 5dtorgb is a very nice little app and does what they claim. Everything is exponential. The more you grade, the higher output 4444 v 4:2:2. 5dtorgb produces larger file sizes, which can be an issue if your hard up for drive space. 5dtorgb will benefit you more should you use superflat settings and intend to do more grading in post. 5dtorgb conversion times are much slower than mpegstreamclip.

Should these guys add the batch processing and in and out points on clips to convert, it will be a real winner IMO.

Disclosure: I do not know, have never met and have never spoken to anyone from Rarevision. Im an end user and came across this app. via this thread.

 

[djkarn105]

Batch processing is very important feature. Very important. I think you can see where I'm going with this. ;-)

So there is a command line interface? It doesn't expressly say so on the web page.

 

[Thomas Worth]

To conclude, 5dtorgb is a very nice little app and does what they claim. Everything is exponential. The more you grade, the higher output 4444 v 4:2:2. 5dtorgb produces larger file sizes, which can be an issue if your hard up for drive space. 5dtorgb will benefit you more should you use superflat settings and intend to do more grading in post. 5dtorgb conversion times are much slower than mpegstreamclip.

Thanks for taking the time to do this. Everything you posted sounds about right, based on the testing I've done. I have a custom Picture Style I've come up with that works well with 5DtoRGB when using the flat gamma setting. I'll include this with the next version.

Regarding speed: at some point I'll implement some speed tweaks, but for now I'm concentrating on stability and adding the features everybody wants.

So there is a command line interface? It doesn't expressly say so on the web page.

Not in the Mac GUI version. I have a Linux version that runs from the command line, but it doesn't have any ProRes support.

 

[Ergin]

Sounds pretty good Thomas. We just shot a music video on a 1d and i will be doing all the grading and fx work,..so definitely will put 5DtoRGB to work. Batch processing in this case will be essential,...if you can write up a simple example on your site or here it would be great.

cheers

 

[Noel Evans]

Thomas, just out of curiosity, what might you be charging for the final product? And Im happy to do a test for the folks here at dvxuser on the non beta version

 

[Dan_Kanes]

This program is an essential tool for any DIT or data manager working with HDSLR cameras. A solid must have. The word will be spread.

 

[TATmedia]

Ummm...Sooo you guys were gonna not tell me about ProRes 422 LT and let me edit my footage in h.264!!!!!!!!I'm lived!!! lol. I converted to ProRes, and good god, does this stuff render fast on my iMac 27" with Core i5 and 4gig ram. With the h.264, it would take forever for ae to render a preview, now it goes in double speed through the renders, almost magical!!! So the next time I do a shoot, I will be using this software to dump all of my files, this is truely a must have. Thanks.

 

[Noiz2]

So not to rain on your parade but the obvious alternative to this is Grinder by Red Giant but I don't see any talk about that or any comparisons. It does almost the same thing your app does except that it can also create an offline version at the same time and add window burns to the offline. Otherwise both seem VERY similar. So it would come down to features (ie if you really needed an off line version etc) and quality.

Has anyone compared the two and if so any conclusions?

 

[Otis Grapsas]

So not to rain on your parade but the obvious alternative to this is Grinder by Red Giant but I don't see any talk about that or any comparisons. It does almost the same thing your app does except that it can also create an offline version at the same time and add window burns to the offline. Otherwise both seem VERY similar. So it would come down to features (ie if you really needed an off line version etc) and quality.

Has anyone compared the two and if so any conclusions?

Sometimes the larger company will provide more features or match the quality, they have more resources, so this is quite probable. But do we really want a world where everything is a monopoly or an oligopoly? If we always buy the standard, we will see less and less innovation from the independents and at one point nobody will bother to write software independently. We will have just one flavour of everything. And then, it will be a rather expensive flavour and a rather boring one.

 

[Noiz2]

Not to interrupt your rant but Red Giant IS a small company. Your right that it is probably larger than the OP's but it is a very small operation.

To be clear I really want to know if there is a quality difference. Guess I could run a test but since this is the direct competition, and it came to market first I assume they looked at it so I'm curious why they don't mention that because the apps with out decent batch processing are really apples and oranges.

And if it makes you feel any better I'm a developer that is MUCH smaller than either of them. So I have a warm place in my heart for the small guy. If they have the better mouse trap I want to be a customer.

 

[Otis Grapsas]

Not to interrupt your rant but Red Giant IS a small company. Your right that it is probably larger than the OP's but it is a very small operation.

To be clear I really want to know if there is a quality difference. Guess I could run a test but since this is the direct competition, and it came to market first I assume they looked at it so I'm curious why they don't mention that because the apps with out decent batch processing are really apples and oranges.

And if it makes you feel any better I'm a developer that is MUCH smaller than either of them. So I have a warm place in my heart for the small guy. If they have the better mouse trap I want to be a customer.

As you mention, Red Giant are far larger than a developer with a single product. They have been around for 8years, they have dozens of tools that are industry standards for some applications and quite popular. It's all relative. When I was starting my camera project, one small company (Cineform) managed to get our entire feedback thread removed from dvinfo with a laughable excuse, when my partner mentioned we will not be using their raw bayer codec. Small company but already thinking in monopoly terms and using their small power in ways a large company wouldn't even consider. Small is relative

I believe both tools should produce comparable quality. We will see comparisons soon. But personally I would support the small developer even if the mousetrap wasn't better in everything.

I checked your site. What kind of software do you do? Audio mastering related?

 

[Noiz2]

Yes a sound FX cataloging software and when it gets finished an audience / donor tracking application for non-profits.

Personally I don't consider a company where the owner replies personally to customer emails to be "big". And I'm sorry but you don't care about quality? You would buy something that didn't work as well from a small vendor over a product that worked better from a larger one? That makes no sense at all. If the products are about the same and the prices are about the same then I would in most cases lean toward the smaller developer. For mostly the same reasons you talk about. But I'm a professional and MY income depends on quality so I'm not going to buy low for some political agenda.

The mixed blessing is that small developers are far more likely to go under and leave you with unsupported or unusable software. To be fair the bigger companies orphan products, get bought and drop support etc. also. Both have happened a couple of times to me with fairly expensive apps. But I tend to lean to the small guy because they tend to listen to you, often give really good support, and make more targeted software.