[Mike Smith]

You may be able to achieve a fair result without buying plugins. At one time there was an AE tutorial floating around on this, though I can’t locate it this morning.

This link shows an approach in Photoshop, which might translate to AE ok ..

https://user.fundy.net/morris/?photoshop06.shtml

[Mike Smith]

Hey Marco

Shame to have all the effort of the shoot wasted in the capture!

Best for you would be direct digital transfer, digibeta to computer, via SDI – a socket / cable interface on the digibeta deck and some capture cards. Capture via analog component to 10-bit uncompressed can also give excellent results, if a good capture card and drivers (from e.g BlackMagic, Aja, others) are used.

Capture to a proprietary codec and then export to your (probably Apple / Quicktime?) YUV422 codec should work well, if the deck / software are truly “broadcast standard”.

My guess, though, is that your facility does not have the kit to do this at full standard, or they would probably have done so in the first place – unless they misunderstood you and thought you wanted it compressed to save disc space ?

Good luck.

[Mike Smith]

A couple of other thoughts.

DigiBeta is 10 bits per pixel / channel – hope they are recording in 10 bit for you?

Also, the lower field info from AE suggests a horrible thought.

They are using an SDI interface to get the signal into the computer, right ? They wouldn’t be doing anything silly like feeding an ananlog signal to a DV / DVCAM deck, and then capturing via firewire – which would explain the DV field order … and could be a factor in a big quality drop, if it went through a composite or y/c connectors, rather than a component connector set …

Mike

[Mike Smith]

So far as I recall, digibeta itself uses a yuv 4:2:2 format with (very light) compression, so that shouldn’t of neceessity be a problem. It’s more likely that the encoding person chose a higher compression setting than necessary / desirable, for whatever reason. Should be worth a free re-transfer for you I think.

[Mike Smith]

That jpg certainly looks compressed, though of course from here it’s hard to tell what’s the footage, and what’s any jpg compression you may have applied.

There’s no sign of wrong field order that I can see. The model must be extreeeemely thin .. or is it widescreen footage, wrongly idented as standard aspect ratio? Even so, I can’t see that re-interpreting the footage as widescreen (if it is!) would make any / much difference to what look like compression artifacts.

Unless it was shot in near darkness … did the original digiBeta look clean and nice ..?

If so, I’d be inclined to return to the transfer house and talk it over with them. It doesn’t look like you have what you wanted – which I guess was a high-quality transfer, no compression.

Good luck!

[Mike Smith]

Sounds confusing.

As Barend points out, PAL is an upper-field-first universe – apart from the DVD codec, which in PAL as NTSC is lower field first. Your Digibeta, going to a YUV codec (not DV codec) should remain upper field first. If using the interpert footage dialog to change to upper-field-first does not fix the problem, you might want to check if you have the same quicktime YUV codec on your system that your facility used – why not call them and ask?

[Mike Smith]

If you’re re rendering to frames, this can be an issue. Do you have an uncompressedm interaced 32-bit codec you can render to which Avid can import?

Also, I guess you’re sure there’s no resizing going on in the import process – the frames leave you “clean”..? And when you preview the sequence on your composite video out, they look good – it’s not a video versus computer monitor comparison problem …?

I know at one time some studios used to ask for frame-rendered sequences to be delivered at double-frame rate – render at 50fps for me, on PAL – haven’t been asked for that in a while though.

Good luck. Messy titles feel horrible

[Mike Smith]

Hi Martin

It’s a market, so I guess you’re looking for an intersection of what you’re willing to work for, and what the potential client might be willing to pay.

To calculate yourself an hourly rate, you could factor in what you hope to earn over a year / week / whatever, what percentage of time will not be billable hours – so how many hours a week you’re trying to earn that it. You’ll also need to allow for the costs of investing in and updating your kit and software, if you see this is a long term proposition.

Armed with an hourly rate, you could estimate how long you might need to do the work, and multiply …

Another approach is to consider what the customer may be willing to pay, and bid for something around that. You could always try a direct question – then decide whether to treat the response as a negotiating bid or as a ceiling. People vary very much in how the like to negotiate – so “reading” your customer right will be important.

You might also think about what quality they want, what alternatives to you they have (and what those alternatives might charge), how soon they want it, why they asked you in the first place (did they like your reel?) – and from that guess your negotiating position.

Good luck!

[Mike Smith]

What would be the drawback of “parenting” the lines to the box ..?

[Mike Smith]

What would be the drawback of “parenting” the lines to the box ..?