processing differences.

[Mike Prevette]

I cant seem to find the differences in these methods provided in RedCine, any clue? which one is better/worse/why? faster? slower?

 

[Rainer Fritz]

I tried also different settings seems by eye the same.... ????????

 

[Antoine Baumann]

box should be the fastest but also the badest. Triangle not far away in term of speed, but still not as good as a sinc filter.

I will do some speed test, but I normaly use sinc for scale down and mitchell for scale up, but I have to say I don't know Lanczos filter.

antoine.

 

[Nick Shaw]

Have a look at the Shake user manual p.863

http://manuals.info.apple.com/en/Shake_4_User's_Manual.pdf

As far as I can see, the choice of scaling filter only affects output scaling, not shot scaling, so you will only see a difference on rendered output when your project size and output size are different.

 

[Mike Prevette]

Thanks Nick! i had long since shelved my Shake books, but it looks like it's time to crack them open.

 

[MikeCurtis]

Triangle/Quadric/BSpline seem to be the leading candidates to me....but of course, different material may be best served by different algorithms. Lots of geometric fine detail vs. subtle gradations with a sharp edge vs....what else?

As a practical matter, I didn't see meaningful processing speed differences between Triangle and Quadric in render times when scaling 4K to 2K for a client last week.

 

[Mike Prevette]

Mike, your my hero.

 

[GlennChan]

A real sinc filter would be infinitely big/long... in practice you'd have to truncate the sinc sequence to some number of pixels/taps.

Lanczos, as far as I know, is a way of approximating a sinc filter with an infinite number of taps. It's a better approximation than simply truncating the sinc sequence.

(I think so anyways... I don't really feel like contemplating math today.)
http://en.wikipedia.org/wiki/Lanczos_resampling

 

[Mike Prevette]

Great link Glenn. I'm a camera guy not a math guy, but every little bit of info is handy.

 

[Paul Lee]

Anyone else find a favorite yet? So far we like bspline. Thoughts?

 

[Miguel "Macgregor" De Olaso]

lankzos should be my favortie, but clearly is softer than linear. So better to avoid.
Linear (the default) seems to work fine.

More interesting than this is that i just saw different rendering times depending onthe preview quality that we have choosen.

Jim said preview affected render times because redcine displays the actual frame that is being export. And he recommended to have the 1/4medium quality when you click export.

However i just concluded that if you are exporting 2K in stardard rendering quality, setting the preview also in 1/2 high gives much better performance than having it at 1/4th.

 

[Antoine Baumann]

I have experimented big difference in processing time between different shots in REDCINE. All with same settings in REDCINE (Full processing, DPX, scaled to RED 2K, etc) and same hard drive config.
The warehouse, IndyCar and all the martial arts shots are processing around the same time, but the Feel My Pain, and all the green and blue screen shots are taking about 2 times more.
Did somebody encounter the same, and why is it so?

thanks,
antoine.

 

[Rob Lohman]

We've been tweaking data rates and this has a big influence on decode times. There's a new REDCINE around the corner which will be a lot faster as well.

It might also depend on the position of the moon

 

[Craig Meadows]

We've been tweaking data rates and this has a big influence on decode times. There's a new REDCINE around the corner which will be a lot faster as well.

It might also depend on the position of the moon

Hey Rob - is that "right around the corner" like the next corner down or a few blocks away?

Thanks!

 

[conrad gaunt]

Lanczos is quite nice, quite sharp (usually quite slow). These are all resampling methods. Linear will be fastest out of these, I expect bspline slowest.

Heres some quadratic bspline code for any programmers out there (pascal for easy translations). I wrote two weeks ago for my MSc, for drawing `closed loops`. Resampling code will be different, but still math heavy. Hence at bottom of list, me thinks. This code is reasonably fast ;-).

procedure uniform_non_rational_bspline_simple;
var
i,j,j2,
sx1,sy1,sx2,sy2 : integer;
weight,x1,y1,z1,
x2,y2,z2,t : double;

begin
x1 := 0;
y1 := 0;
z1 := 0;
for j := 0 to control_points-1 do
begin
for i := 0 to segs do // line segments
begin
t := i/segs;
x2 := x1;
y2 := y1;
z2 := z1;
x1 := 0;
y1 := 0;
z1 := 0;
for j2 := 0 to 3 do
begin
case (j2 mod 4) of
0 : weight := power(1-t,3)/6;
1 : weight := ((3*power(t,3))-(6*power(t,2))+4)/6;
2 : weight := ((-3*power(t,3))+(3*power(t,2))+(3*t)+1)/6;
3 : weight := power(t,3)/6;
end;
x1 := x1+(cpa[(j2+j) mod control_points].x*weight);
y1 := y1+(cpa[(j2+j) mod control_points].y*weight);
z1 := z1+(cpa[(j2+j) mod control_points].z*weight);
end;
if i > 0 then
form1.image321.bitmap.LineS(round(x2),round(y2),
round(x1),round(y1),$ffffff);
end;
end;
end;

We've been tweaking data rates and this has a big influence on decode times. There's a new REDCINE around the corner which will be a lot faster as well.

It might also depend on the position of the moon

Good job Mr J has resources, now lets move that glowy sucker moved to a more optimal position!

 

[conrad gaunt]

!!! moved above