#apertus IRC Channel Logs

Greetings Sebastian

fine fine :)

I'm well, but my head feels horrible from a serious lack of sleep ;)

I will in a few hours. In regards to the next general meeting, could we schedule it for Tuesday night (around Wednesday 12am in Sydney) next week?

Thanks :D

morning everyone!

hello!

then tried to order from firstcut

"error processing your order" :)

hehe

btw, did you adapt the seal area?

it might be a good idea to do that, so that we can actually seal the sensor off with a piece of plastic lateron

*area

you mean the palstic is put in from the "front" (lens side right)?

ATM, we have a gap, as the inner shape near the seal area is much larger than the seal area

https://www.apertus.org/sites/default/files/alpha-lensmount02.jpg

firstcut just called me

how much overlap should the seal area/metal/rubber have from the sides?

i.e. nothing should really need to touch the glass area

should the inner aluminum "window" also loose the rounded corners?

ok :)

got it, what do the colors represent?

and the blue overlay is how the lens mount IMHO should fit

the blue(lens-mount)-red(glass) distance should be at least 0.5mm

(more is probably better here)

and should probably have a cutout equal to the glass area

we want the seal area to overlap with the lens mount bottom as much as possible without hitting the glass area (in the xy-plane)

https://cloud.gerade.org/public.php?service=files&t=88644302ffde4f6e5659627a3c8bbf32&download&path=/Axiom/lens-mount---seal-area-01.jpg

option 2 window slightly inside seal area (2mm overlap)

that should completely overlap the seal area (that's the purpose of the seal area)

(and to be on the safe side, I'd keep a distance of 0.5mm to the glass area)

with window you mean the rounded rectangle visible at the bottom of the lens mount, yes? yes

I just make sure the distances are accurate to the glass area (0.5mm)

*area

understood

7.1 contains the data

where the seal area is 34.7x33.8

in the scans the glass extendes further outside than the groove in the ceramic

actually two horizontal and three vertical

on the top, you see the gold pins in the first and second step

on the left you see the bar-code like stripes on the first level

the glass are seems to be inside the first groove

I see, perfect

https://cloud.gerade.org/public.php?service=files&t=88644302ffde4f6e5659627a3c8bbf32&download&path=/Axiom/F-mount%20to%20CMV12k-V04.pdf

should I create STL for you as well?

ah, one thing

59mm total width

yes

will take a bit again until its reviewed

not yet, was busy during the weekend with all kind of stuff

(i.e. definitely before we get the sensor)

(last time in the lab)

nope, left it at home, you want it?

ok

since we cut away a bit less its 5 € cheaper per piece ;)

hi PhilippeJ

is that a problem for us?

we are talking black POM, yes?

okay shouldn't be a problem then, what would be the difference for a perfect finish?

there is no option

okay, so nothing we can do about it anyways :)

and ordered!

he must be very happy he found a buyer as he has not replied to me for a week so far after I said I wiould buy it

hello !

good idea I ll contact the other f65 sellers as well now

off for a nap ... bbl

is there anything else you want to prepare/discuss before meeting them?

let me check

on the crowdfunding campaing

would they like to partner with us somehow ?

(sorry postedtoo fast

can you explain me how the sensor is attached

is it the sensor socket ?

like backing the campaign when the time comes

which is aluminum and in the new version I just ordered a hard plastic

sensor mount

?

yep

at least I know what we do

?

hmm, I am afraid we dont know exactly

latest crowd funded camera: http://www.indiegogo.com/projects/panono-panoramic-ball-camera

se6astian, is the lens mount much cheaper with hard plastic ?

I need a bit of help with regular expressions

$txt = preg_replace('"<!--import-ignore-start-->[\\s\\S]+<!--import-ignore-end-->"', "", $txt);

but now the problem seems that I have multiple of such tags in the content

back now ...

regular expressions are not the best choice to match strings

what exactly do you want to do?

basically this: "some content that should stay <remove-start>some content that should be removed<remove-end> some more content that should stay <remove-start>some more content that should be removed<remove-end> and some content that should stay"

what file contains those tags? i.e. what syntax/semantic does it follow?

html

http://regexr.com?375j3

haha, the "?" did the trick

many thanks Bertl

it works

though the colors are "anywhere"

Oh the dng converter is done! Great!

well, I uploaded a png as well IIRC

yes I am looking at the png right now

*near

yes, I'd be interested in the code as well

you need numby as well

the self_10ms.raw16 file works fine though

yeah, I know why, it is because the reader doesn't check that the image is Y flipped

ah yes!

emailed gabe

welcome gcolburn!

I wonder why :)

to get rid of the fixed-pattern-noise we should try this approach: https://en.wikipedia.org/wiki/Flat-field_correction

se6astian: yup, that is what is planned

this will, as a matter of fact, be the default, but it is recorded in the sensor registers

we won't be able to do X flips because we only have 32 channels

i'm looking up the mirroring in the spec right now

okay. you can specify either in the DNG, and you can also specify mirroring

with y-flip disabled, naturally the image is flipped

this is the result of the coordinate system the sensor uses

I'd definitely add the registers to the dng, we will need them later, but for now, a simple change to the other pattern should suffice

I'll look at the new file and try to add the registers when I can

yeah. its been a good learning experience to understand TIFF/DNG. To implement the full spec as a reader would be a lot of work. luckily we just need to write DNG files :)

can be reused elsewhere as well

when I was reading the spec, one implementation is just a sequence of DNG files numbered appropriately

hey FergusL

rawIFD.getTag('CFAPlaneColor').value[0] = 1 #G

rawIFD.getTag('CFAPlaneColor').value[2] = 0 #R

yeah

maybe by reading the file backwards ?

I had issues with the Y inverted (or not) pages

Does adding that fix it?

gcolburn: not really

we cannot rearrange the data

we can always flip it, but that will require a mirror tag

rawIFD.getTag('CFAPlaneColor').value[0] = 1 #G

rawIFD.getTag('CFAPlaneColor').value[2] = 2 #B

this gives something which could be correct

are you setting the white balance?

i don't have any code to determine it, so its using whatever was in the original Canon image with its profile

good then add the tags above for now and we should be fine

btw, why can't we remove the canon info?

we can do that. I just need to look at the calibration array details and set it to neutral

I see, okay, so probably next task

and please try somehow add the registers as binary blob

s/try/try to/

gcolburn: so that we can extract that information lateron

https://github.com/apertus-open-source-cinema/jp4tools/blob/master/JP4toDNGconverter/source/elphel_dng.c

https://github.com/apertus-open-source-cinema/jp4tools/blob/master/Movie2DNG/src/dngwriter.cpp

(gcolburn: why python, if I may ask ?)

their sdk would probably be the best route if one wanted to read any DNG. but for writing I figured it would be simpler to just write some code

the adobe sdk is rather slow as the author of the above code noted

much faster

yeah. I started on a C++ version but I haven't had time to work on it. prototyping in python has been helpful

yes

important

just create the image with seeks first and then dump it to stdout

irrelevant, we are talking output

ok

(lossless compression I mean)

"Two Compression tag values are supported:

•Value = 7: JPEG compressed data, either baseline DCT JPEG, or lossless JPEG compression."

hmm, okay

yeah. I'd probably need to find a library to do the compression.

hmm?

25222907 Nov 12 19:24 CMV12000_DNG_Writer/img.dng

this is what I'm talking about

i.e. we want to compress the DNGs somehow

bash script?

what do you mean by "seeking" ?

to do that, it needs to move back (seek) to the beginning, which is not possible in a pipe

okay, got it :) thanks guys

to write it without seeking, i would have to calculate all offsets to where the tag values and image will be in advance, and then write them out at the beginning. sometimes TIFF stores the value in the tag, and sometimes the tag points to the value, so pre-calculating all this would take a bit of handling different cases

I think Bertl suggestion is great

here's the code you can append at the end:

orientationTag.tag = 274

orientationTag.value = np.zeros(2,dtype=np.uint8)

orientationTag.value[1] = 0

dng.ifd.tags[274] = orientationTag

3 = The 0th row represents the visual bottom of the image, and the 0th column represents

4 = The 0th row represents the visual bottom of the image, and the 0th column represents

there are other options as well

1 is default

or use resize() before each write() call

stringio provides a file like class in memory

I've got to head out for a bit...

i'll look into those options

looks better

Bertl: for the love of all that is holy, do not use the 8bit jpeg compression aspect of DNG. It destroys images.

do not worry, we have no plans to use that :)

yeah, not doing 8 bit jpeg compression

because we really can't guarantee anything won't happen that its technically possible for a user with the right skillset to implement

but we're definitely doing lossless raw

which is basically the same principle as a zip file or a tarball, just using entropy encoding

rexbron: the beauty of open source/open hardware is that the user is not forced to anything

even if the community or the developers do not support what you want or do not want, there is always the option to hire some developer/programmer to add/remove the parts you like

I honestly doubt we'd be able to keep lossless raw support off the axiom even if we tried

(and I would expect something like that to be part of the DNG specification)

Bertl: perhaps there's a mode that separates the planes?

Bertl: what do you mean external compression?

if there is no lossless compression in dng working on the image data, then I need to compress the dng as binary blob

Here is what the DNG spec says: "For lossless JPEG, the internal width/length/components in the JPEG stream are not required to match the strip or tile's width/length/components. Only the total sample counts need to match. It is common for CFA images to be encoded with a different width, length or component count to allow the JPEG compression predictors to work across like colors."

okay, so that might be an option after all

dng allows for lossless jpeg compression, which should give about 2.5:1 reduction in size

well, it's probably better to keep the two green channels separated anyway

I'm not quite following everything here !

I'd rather avoid having our own raw format unless it provides a clear and tangible benefit

which I doubt is possible unless somebody designed DNG in a very stupid way

(50% = reduction to 2/3rd)

Bertl: so how is it going with the IT8 chart ?

it's up to you folks to make heads and tails out of it now :)

it's in the same folders as others ?

in the raw folder, yes

Bertl: do you have a color temperature value for the incandescent source ?

nope, but the guess around 2900K is probably valid

which I suspect is only possible if they're blocking data for huffman in a stupid way or in pathological corner cases

rexbron: right

and that could again become an *option* for say shooting longer with the same cartridge

The feature I shot was 10Tb of camera originals by the end of the 8 day shooting schedule

dmj_nova: different beast entirely

that's more factual than documentary, semantic difference but important

right now the "custom raw format" thing is just a thought experiment

dmj_nova: sure, experiment away :)

I don't think we need to 'define' the audience, we will simply see who shows interest

Bertl: unfortunately you do. You can't change camera ergonomics easily or cheaply. Pros don't scream loudly, amatures and hobiests do. Blackmagic's forums are proof enough of that.

rexbron: Bertl: it really does need to be a highly useable tool for filmmaking foremost

Here is a link to my BMCC rig, http://imgur.com/Rp7Z9bt

the actual body I mean

Bertl: that's why i'm here ;)

http://www.aaton.com/images/delta-700c.jpg

too bad it bankrupted Aaton

dmj_nova: Notice how it's curved, meant to put the center of balance below the shoulder, not above it

notice how the viewfind is integrated into the body but ajustable

maybe it might be a good thing to put the various aspects together in a document (via email to the mailing list or probably even better on the wiki?)

rexbron: so it's designed to be ergonomic for a 2-3 person team to use?

btw, are there 'left handed' camera(wo)men?

personally, I would like to see the axiom as having a "brain" and a "shell"

dmj_nova: that sounds like an epic and epics are terrible to work with in production

the image is great

but all the ergonomics of the camera were sacrificed for 3D

the Epic was designed to be the smallest it could be to shrink the size of 3D mirror rigs

as a result, the camera has no mounting points for accesories

great for modularity, terrible when the director wants to go from studio to handheld and it takes 5 minutes,

I'm not saying that there isn't a place for that form

dmj_nova: yes

also consider cost, do you want to put that into a body that just works or do you want to create a secondary ecosystem for camera accessories to make your body work with the exisiting equipment standards

Bertl: the epic, Aaton or BMCC?

your rig

it's a pain in the ass that cost me more than the body

rexbron: my own thoughts for a "shell" system is that the shell should be a complete and singular thing

another example of Aaton's style of design

Bertl: two, the built in touch screen and SmallHD AC7

rexbron: what's the thing on the right side?

ah, so that's the battery ..

rexbron: have you seen the axiom modules concept?

Yes, I have a feeling we'll be learning more about that quite soon

am I right on that se6astian?

not sure what the final plan is

which will get a shoe box :)

rexbron: I'd imagine that a shell would fit around that assembly in the concept

so we are already far ahead of that then :)

dmj_nova: depending on the production, studio mode may consist of just a tripod, so having an arri standard dovetail and shoulder brace makes it fairly quick

note to self: never put a production zoom on my moco rig

Take my rig for example

it's not balanced at all

but since that rig is nearly all alluminum, it already weighs 25lbs

but you get into rediculus dslr style rigs

So you're saying that weight distribution is key

also by lowering the center of gravity to below the shoulder, you get less shake

http://www.ocon.com/inspiration/labs/rod-standards-explained/

In North America, the east cost uses 15mm studio offset and the west cost uses 19mm. troy_s_ does Vancouver use 15mm or 19mm?

Axiom, be it with a shell or not, should adhere to those standards to accessories just work

not sure what standards there are (to accessories)

yes, we should support standard accessories

dmj_nova: Mostly my complaints come as an assitant. You rent a Red from an owner operator and it's missing half the things you need to make it functional.

is Axiom including rental houses in their target audience?

so it's got rod compatibility, but it doesn't come as a functional unit?

huh, I can't save an edit to a discussion page on the wiki without getting into a captcha loop

ah

then how do they use it, just making do with minimal stuff?

Canon EF mounts on the epic is the biggest culprate

so like a big dslr with worse ergonomics than the Canons

dmj_nova: yup but the operators try to get full rate for the rental

as little as they can get away with

great essay on camera egonomics

I will say that DSLRs have brilliant ergonomics for a box camera

dmj_nova: for stills, not for motion

and that's not to say it can't be done

the hardest part is stabilization and follow focus with them

they're much better at the things that a cinema camera on the shoulder isn't good at and vice versa

nope, got a message saying the link I posted was blacklisted

let me check

With future capture power arriving in smaller camera bodies we increasingly have to choose between two types of camera form and two distinct operating possibilities: Box or Balance. Rigid stabilization, tripod or otherwise, will limit some of the differences between these two forms. However, if we’re departing from stabilization we’ll have to make the choice between capturing with a Box Camera in our hands, or a Balance Camera on our shoulder. A

can you save the page just without the link?

I moved you into the "emailconfirmed" group

ues

great

ok, well I need to head out to dinner with some friends. It was great chatting with you all!

yes the captcha is always enabled

se6astian: So I think we may need to design separate "shells" for Box and Balance

time for me to go to bed