ARC--Arriraw says 2880x2160......

[celboy]

but in ARC it is opengate

The hd dailies seem to map to opengate'

but baselight & resolve say 2880x2160 & don't display full width

In ARC 3.4 when I select "just" opengate..(not 4:3 or 6:5 from OG) I see what I am missing.
But it seems I am unable to render 3.4k files ........all my renders come out 2880

I have overwitten the way the raw is reading (off the clip settings) to be now manual
clip settings default to "4:3 off OG"
I am now just OG

What am I missing here?

see attached

thanks,
TomT

[celboy]

Ok I got the rendering to work.....but should the metadata have been tagged as OG & not 4:3 OG??

[Jan Heugel]

Dear Tom,

the footage has been shot with ALEXA Mini in 4:3 mode. That is the desired resolution by the camera crew.
Due to camera internal processing in the Mini there ate three formats where the camera records Open Gate resolutions but marks the "active image" as being a specific/smaller part of the image. In ARC you can use that extra but not intentionally used area.

Bildschirmfoto 2016-10-10 um 09.49.12.png

Please make sure you do not change the image aspect/use a different image area if not requested!

Here's the overview on all of ARRI's recording modes:

2016-08-30_ARRI_RecordingResolutions_SensorArea_2.1.pdf

Cheers,
Jan

[celboy]

Thank you for the quick reply.

So the active image has been set to 2880. And it is visually anamorphic.

But the HQ HD QT dailies I received extend to the full sensor width (visually beyond the 2880) & have a letterbox of over 3:1.

Is that probably operator error?

Is ARC the only way to access the "extra area"?

thanks,
TomT

[Jan Heugel]

The QTs you got must derive from a tailored solution. What is their resolution (with and w/o letterbox)? As far as I know ARC is the only tool to access all of the image information since our SDK listens to the active image area when passing on image data to the various programs.

[celboy]

The qt is 1920x1080.
I measure the image to be about 620 pixels high.

It has camera lens metadata that I can see thru baselight browser. Which makes me think the qt was made in camera.

So based on this scenario, is it possible to make improperly formatted qt dailies in-camera?

Thanks,
TomT

[Jan Heugel]

Dear Tom,

have a look at the pdf linked before: all possible ProRes resolutions of the ALEXA Mini are in there. None of those is a letterbox format.

A de-squeezed 2.39 would give you a height of 803 px (1920x803).

Cheers,
Jan

[celboy]

Ok , but wouldn't a de-squeezed 1.55 OG give me that?

thanks,
TomT

[Jan Heugel]

Yeah - but not created by the camera or by ARC: for OG footage with a 2.0 de-squeeze you get a 1920x804.
Choosing 1.55 always results in a native render-out as 3424x2202.

To end up with a de-squeezed OG in HD resolution:
3424x2202 > desqueeze > 3424x1101 > resize > 1920x619...

[celboy]

Jan,

Just to be clear here.

The mxf's were OG with a 2880 active image (4:3 from OG is the default clip setting in ARC) & shot anamorphically.
The hd QT's were hd with a letterbox reflecting full width sensor & squeeze.

Am I correct,..... in that you are saying..... that those qt's could not be created by camera?

What application outside the camera can "open up the gate" to see full sensor & render a deliverable & then "cover/mask up" the full width sensor and save as a 2880x2160 raw file?

I appreciate your patience with me as I try & wrap my head around this.

TomT

[Jan Heugel]

Hey Tom,

yea: If you have clips holding the same image content as a MXF/ARRIRAW and a Quicktime file, then there's no way this file was created by the camera - the Mini not record two formats in parallel. Further more - look for yourself - there's no "camera delivery format" that creates images with a height somewhere around 6xx pixels.

Why not ask the post/people you got the files from how they created those files?

Cheers,
Jan