#apertus IRC Channel Logs

good morning

morning folks!

massive wiki restructuring done

https://wiki.apertus.org/index.php?title=Special:RecentChanges

we will never find anything again ... :)

lolol

much better than a lot of wikis ive seen

Live screencast for getting started with phabricator on Tuesday: http://lab.apertus.org/calendar/event/view/1/

bb in the evening

Run for the hills!

Finally, its nice to get a large project finished. Alot less stress...

What the flying hell? Bertl_oO has the camera now turned into a DSLR?

Bertl_oO: And so it begins.

Make whatever one likes, I would caution against a straying from the original design vision however.

Rather that it is critical, from my stupid and useless vantage, to keep a keen eye and focus on the design for the main shipping point.

As the design drift is incompatible.

(And I really wish Seb's original idea to draft women happened. This sucks in here.)

how so?

good evening

I believe in culture, and this one is horrifically lopsided. It was brought up before by seb, and damn if I didn't think it was one of the most pressing issues.

we have women here, at least one

Thank god.

Sort of a bogus argument actually.

so our part is to make it more interesting :)

but at the moment, the channel doesn't seem very appealing/interesting to them

We received another indiegogo contribution today - I can't reproduce this? maybe someone still had the perk displayed in a cache?

se6astian: Probably.

Just not a published link now but still active?

yes

As a total newb in board design, how do you intend to iterate this down to the final form factor?

no, we are already working with the Beta dimensions

both, sensor and interface boards are squares, the width of the Micro/PicoZed

but we still need to do some iterations to get the electronics right

The bolt pattern is fixed on one size and variable on another.

troy_s: please do that would be great!

se6astian: Looking for the Alexa bolt pattern or Sony.

does every manufacturer do it differently

Yes.

Extra is holed out for weight on camera accs.

The bolt pattern on the bases of cameras is standardized

And almost every camera I have ever touched has the dual 3/8s for the Ronford Baker quick release clasp to affix to.

Actually worrying. ;)

Asking on a mailing list for 1st ac feedback would be helluva prudent

rexbron: PING

Bear in mind that for top mounts you need a good number of mounting holes to base top plates out

This would also accommodate securing for mounts to other things such as cars etc.

agreed

And bore 3/8s into the top down

And the top plates can then be customized.

Sides too, if you can get one or two, are always welcome.

Honestly though, this sort of “non issue” as it seems, is a _huge_ issue on set. To the point where some cameras are not even considered due to the fsckery you need to cage them etc.

se6astian: Many bodies have a locator pin too. See Alexa.

all to the thread please, every tiny details!

Because stillsies will want 1/4 20 which is junk for motion picture making.

I think it should be trivial to have two base plates for the case

or just several holes of 1/4" and 3/8" on the bottom

That bottom bolt pattern is critical though.

Otherwise you are going to be expecting custom risers and all sorts of other crap.

I get the feeling that the Beta should not yet try to do everything already in the first step

LOL. It is height and bolt patterns.

Just make sure to meet the standards, doubly so on a beta.

.

;)

the pattern can be adjusted to whatever fits the size

:)

no, actually the height is fixed to the Beta height, as the sensor is in the center :)

God.

(if they think they need)

Genius.

C'mon.

Get a damn 1st involved.

Right. And there is nothing in GIMPs design docs about scene referred imagery.

So expecting a culture to offer up insights on something they have no clue about is.

what I'm saying is, if it is so damn important, why don't we have any wiki entry about it?

Because. Culture.

yeah, then folks have to live with the results, that's how life is

I give up.

we can't guess everything which is 'important' to somebody

developers for the Beta

You can only design to one.

I pick developers :)

Can't wait to use that camera.

Think about glass

That goes in a tray

One simple ridiculously trivial bit of research

Now think about rods and other baseplates

Now think of levels and ball mounts

Or you don't get that, and your culture grows in another direction.

Am I being unreasonable?

imagine everything fits but the camera cannot finish a single take _because_ there is nobody who developed the software :)

And short on shooters

I don't see that at the moment

Well by long I mean “a very few talented devs”

I think there are many good developers out there, they just do not have a chance to develop

And there is a whole legion of things that

Having hundreds of developers without anyone wanting to use it

agreed

all I said was, the placement of the sensor is fixed

there is a minimum height (2.25"/2) which is always there

Yes.

The base size was often off of legacy film height

figure out what the optimal height is, let us know, then we can discuss about the baseplate height

a 3" baseplate doesn't sound very plactical to me though

4"-1.125"

Height from plate to lens. But the reference that you two need are for the two types of rod sets

Namely height from rod after plate to lens

troy_s: please describe all things that are important for you into the wiki! I even can not read as fast as you are writing :))

I cannot daFred... I must shower or suffer divorce. :)

This isn't important to me. At all. But for your independent filmmaker audience it is a critical point.

LOL

Someone here nag rexbron

troy_s: bring you'r wife here, this will raise the percentage of women dramatically and we will convince her that you do not need to shower right now :)

LOL

Seriously though, at this phase of design, the project desperately needs an experienced first.

rexbron has been interested and helped previously. Nag him via email.

(with link to this irc log)

Done.

Bertl: Some googling http://matthewduclos.wordpress.com/2014/01/27/iris-rods-a-simple-explanation/

Bertl: To explain further, that blueprint that Duclos has is from the rod mount plates to CoL.

Hence the requirement to nail the bolt position and lens height such that an off-the-shelf system can be immediately slammed onto the camera and used.

we have this arri sketch in the wiki since 2012. ( https://wiki.apertus.org/index.php?title=Rods ) you are welcome to add information to this page...

daFred: too many years around libre software; I loathe wikis

Sure.

I will leave that for more able bodied types.

And it is not pleasurable adding stuffs to wikis and other things.

what should we use? dropbox?

there will be help: see @13:15 se6astian -> "Live screencast"

http://lab.apertus.org/calendar/event/view/1/

hi

even if it's treated as an optional extra, it should be a clear option when ordering the Beta IMO

rather than just leave it to users to figure out

se6astian: yup, will do

if there's any intention of using the Beta to shoot usable footage, it's essential

there are also software solutions to reduce moire and step artifacts

ok

(not just OLPF)

like rainbow/false colour gradients on fine meshes

o.O

optically filters of high frequencies in the scene before the light hits the sensor

closely related to nyquist formula

correct, so, basically what effect has that on the sensel?

a pattern which is (way) larger than a sensel

and a pattern which is (way) smaller than a sensel

you agree?

giving 'rainbow pattern' effects

AFAIK it essentially blurs the image very slightly

so there are no spacial frequencies that would cause interference with the sensels

but again, I'm -really- not the right person to discuss this with :P

large enough to avoid 'single' sensel effects and small enough to be acceptable

(IIRC)

I have been looking into it a bit.

Hence why I think Glen Chan's idea to leverage the components against the result is damn genius.

troy_s: any link for that?

That you “cage” the result such that you can't get completely erroneous results

intracube: Google Glen Chan Toward Better Chroma Subsampling.

(and add it to the wiki please :)

as alias artefacts would be burned into the image

Yes screwed.

The idea is quite simple and elegant really... If you visualize worst case on a subsample is stripes of say, green and black.

The green vertical rows would be totally black

So the non-black stripes would contaminate the no data region

Outlined in that paper. It could be pushed into the XYZ domain too to further the results.

note that HDMI doesn't mean interpolated

Hrm. Never much thought of that.

Bertl: which is why I said HDMI to Atomos :P

well, even the Atomos supports 'raw' recording, granted, only with 8 bit which won't make you happy

YCbCr isn't exactly debilitating.

again, depends on the interpolation

YCbCr with equal number of components?

RGB raw to YCbCr would be crosstalk.

(which I disagree, as it is a simple matrix operation)

as long as you do not interpolate or decimate, you're fine

But if the intent is to go from raw RGB “primaries” to broadcast 709 YCbCr, then the result could be a matrix with offsets.

So no dice.

LOL

Good.

feel free to goof around for good here :)

troy_s: if you mean this: http://www.glennchan.info/articles/technical/chroma/chroma1.htm

I think that is it.

It is subsampling. Precisely the same issue.

which isn't the same thing

which is where OLPF/moire/aliasing issues crop up

The sensor is chroma subsampling

Only difference between the YCbCr and Bayer is citing

for example, if you've got repeating black/red bars at several times the spacial frequency of the red photocites (but not an -exact- multiple of)

sensor (or anything after in the chain) has no way of knowing the true spacial frequency of the bars

Exact same issue

intracube: may I suggest to devise some practical tests?

Same issue Glen addresses in a portion of that work.

intracube: i.e. create some actual test pattern with a known test procedure, so that it becomes easy to evaluate effects and the benefits of certain OLPF solutions there?

I don't know what that means

that's fine, as long as it is properly specified and the procedure to test with it can be recreated

intracube: Take a hole in an image. Now guess (via scaling or such) at the color in the hole via the surrounding colors.

troy_s: Bertl: https://lh4.googleusercontent.com/-7SjeYd-KE-A/VEwTpE5up-I/AAAAAAAAA64/x9CmTa-MnuA/w409-h722-no/sensor_sampling_nyquist.png

I am pretty familiar with sensor layouts right?

Exactly

c) high frequency pattern shining on red sensels

Your lens resolves to those sensels

That is all VNG / Amaze etc resolves. Nothing magic.

Bad colors come up because the values on say, two channels, is discontinuous with the values on the guessed hole gap

Which is why I said to look at Glen Chan's work, because it guesses and restricts based on the color domain

It is vastly easier to understand.

The red gaps in your image, if it were purely red gradient, would weight the blue and green collectors accprdingly

but because of RGB sensor layout, effectively the digital sampling filter width is too narrow

therefore aliasing artefacts

And based on your guesses, you can get bad (really bad) guesses

Say the actual color is a highly saturated color

So green well at the site is very full

why would red bars register at all on green/blue sensels?

Well the filters are non-narrow band

And illuminant and other such rubbish will refract / reflect differently (hence post spectral)

Bertl: Disagree. Too complex.

Bertl: The frequencies are totally post spectral.

But not a huge deal.

Sure. But your glass too would get in the way.

I actually had very good results with illuminating the sensor via LEDs directly (see contraption :)

it would be relatively simple to project a pattern onto the sensor for example

True. That might be a fun test.

troy_s: I still don't understand the solution/workaround you're suggesting

intracube: You look at the data and use piecemeal color to restrict the result.

Once you know the luminance qualities of the sensor for example, via a profile, you know valid and invalid values for s given range.

So a degree of the false colors can be ruled out.

The red fires. The blue and green do not

So our example, the red data plane is solid

Erf 1.0 red

The value would still be 0.5

"<troy_s> So our example, the red data plane is solid"

the point is it wouldn't be solid - there would be false gradients all over it

It would be full red on only the red plane

It would be 0.0 at those positions, pulling our scale values down to say, 0.5

But if we know the sensor, we can say “Red can never be 0.5 when blue and green luminance is zero”

troy_s: sorry, I can't follow this

anyway, the argument for an OLPF is simple:

take a color which is actually a mix between red and green for example

let's say it registers on the sensor 50/50

now take a pattern which is about a sensel wide

depending on where the pattern starts

then both sensel (red and green) will always give the expected result

there is no way to compensate for this in software or post processing

(or fitted into the lens mount at some point)

Bertl: I don't know if the OLPF distance from sensor matters

Bertl: if you're shooting nature/landscapes - yep

man-made environments on the other hand....

note that the problem is the same with any bayer pattern sensor

the only way to avoid it is to either use separate sensors (one per color) or to have stacked sensel (i.e. RGB in one pixel)

Smearing the data is a cheat

Thats what I get, missed alot. Hey bertl good stuff on the DSLR, great marketing tool. Include some standard dslr shooting functions and even a separate possible viewfinder attachment. I have more than a few photographers I know interested in an open source DSLR that could double for video. If anything Beta is almost made for it.

Its two separate emails for marketing and engineering both related I need to send yet. XD, im glad to see the idea at least is on your guy's mind.

Interesting.

which in theory is more accurate or pleasing.

accurate from a subjective point of view of a person watching the video, of course depending on circumstances XD

but usually they are different from the ones which make the camera sensor trip

with it too, just needs a different 'original' pattern :)

if it really doesn't have that problem, then it has a non bayer sensor

Rebelj12a: not easily fixable in post

Rebelj12a: if it has a bayer pattern based sensor, then it cannot avoid this problem :)

ahh

time for bed

ahhhh so for instance the olpf filter for the 5d Mark II isnt necessarily a good thing. Especially if it isnt made well I know OLPF can cause all sorts of problems.

intracube: It is _as huge_ as how you scale your YCbCr data. Huge. Huge. Huge.

And my gut says it will destroy 99.9% of the current debayers on a number of axes.

Oooh destroying things, is that good?

Hi Bertl :)

Blast destroying things is fun haha

__anton__: I would suggest subscribing to the axiom-dev mailinglist, but the action is mostly here and on lab as it seems

*phabricator

Heh, I'm supposed to be a competent computer user. I got a google account. Yet can not figure a way to join axiom-dev. I get as far as here: https://groups.google.com/forum/#!browse but then I can not find the group via search :(

wescotte: were you able to join the group?

wescotte: that's my question, what exactly do I need to do to join?

__anton__: I don't see any info on how to subscribe either... Maybe somebody here knows otherwise I bet if you just send an email to *email address removed* it will send you instructions

so it's not a public mailing list

intracube: It is probably easier to see the issues when you peel apart the data.

Bertl: thx

troy_s: So did you say camera bottom could mimic Arri Alexa?

troy_s: it says optical center is 99.8mm over plate, there are two 3/8 holes 10mm deep, 40mm apart, also some weird oval hole there 7mm wide 8mm long 4.5mm deep

troy_s: Is this your ideal camera bottom design?

troy_s: :) what's that oval hole for?

__anton__: As well as hitting the existing specification for height to lens to coexist with the existing gear (that is _horrifically_ expensive to buy for most indies.)

troy_s: page 4

Just looking at your quote that is locator.