#apertus IRC Channel Logs

off to bed now ... have a good one everyone!

i will prepare a place where the AXIOM beta can be seen at 32c2, maybe in front of halle G

good day

parasew, at what time?

wakalixes, just sent you an email -- around 16h would be good, since there is too much before;

we would have an assembly table, but maybe this is full, we have to see

i am still waiting for confirmation of a meeting, if this does not take place we could meet already at 15h

yes!

morning folks!

gotta go

sgi rgb?

but the 32c3 logo seems to be black and white, no?

yes, black and white

the problem is, you can do rgb as well, there are enough colors available for the overlay, but it is based on a very specific indexing system

can i use imagemagick?

you can use whatever you like to generate the image (combine it with the beta overlay at the end)

(size needs to be 1920x1080)

ah ok so straight forward 8-bit rgb

hey

getzi how did you convert the last image?

can you paste your commandline=

yes i know :)

channel 0 (red?) is used for encoding 8 bit grey and channel 1 (green) is used to determine transparency

move the alpha channel (probably inverted) to the green channel

you can take the overlay_05.rgb in /opt/IMG/ as example

ah super, thats a good idea

(i dont have the beta with me at the moment)

probably, no idea where though

parasew: you left the Beta alone?!

of course not :)

its next to me in the bag

but its not assembled

you took it apart?!

no worries, just pulling your leg :)

there are some crowdfunding-backers here at 32c3, also a lot of interest for the camera

well, you can show how to enhance the ming.c by adding a full RGB mapping for the overlay?

it's actually not that hard:

shows you what the upper 4 bits mean

a_v is the live view data (12bit, 3channels), b_v are the lower 12bit of the 16bit overlay data

c_v is a 4bit subvector based on the channel

any rule which involves scan_fcnt() is some kind of flashing/blinking

which would make it semi-transparent (50/50 mix)

mode 0000 means full transparency, i.e. only live view

in mimg.c, there is an 'if (opt_overlay) {'

where the current mapping from .rgb to overlay data happens

sure, why not, only the mimg is currently very inefficient in loading an overlay

yes, but it should be fine for now

probably

(questions that i cannot answer :)

when will you start the presentation/q&a ?

there are not much ppl, approx. 5

so probably not before 16:30 that you will have many questions :)

but i just wanted to show them the basic interaction with the beta now

we might take ca. 15minutes to find a place and build up

is the image-ram connected to the fpga or to the arm section

both

https://reference.digilentinc.com/_media/zybo:zyng1.png (this is for the zybo, but it is identical for all Zynq)

good evening

/opt/BERTL/ming.c

thank you :)

https://www.cinema5d.com/battle-of-the-camera-underdogs-blackmagic-design-vs-apertus-vs-kinefinity-on-the-couch-ep-27/

hi all!

\o/

don't forget to take a picture of the overlay

basically all the Cmosis sensors are available with documentation

one of the cheaper sensors is the CMV2k/4k

with 2 megapixels/4 megapixels

as the AXIOM Beta allows for different sensors, we will also support the CMV2k/4k i the future

we will also investigate the CMV20k (which is larger than the CMV12k, but also more expensive) in the future

se6astian knows them, but they really depend on the quantities (and can be requested from cmosis)

i was wondering if we could theoretically use a cheaper sensor solution as alternative to the 4k one currently in use with the beta. there are a lot of developers interested, but they would also trade image resolution for the possibility of an open source cam :)

maybe a *beta-light*

cmv8000?

not that interesting, IIRC

yes, i just wanted to know how much work it is to implement another sensor

and of course, software support, but that will be not too much different from the cmv12k

(the one listed here http://apertus.org/axiom-beta-imagesensors )

ah ok.

is there a possibility for a cheaper still image sensor?

also remember that the sensor is a major component of the Beta but not the only one

cool :)

but also note, that you can use the Microzed as stand alone development board too

but with the gamma we dont use microzed, right?

but would we use this custom solution in the beta at a later stage?

parasew_: unlikely

ah ok..

everything :)

you can do all kind of false color settings with the transformation matrix

for example

cmv_snap3 seems to not have all the settings as stated in the wiki (-x is missing? -n?)

(i.e. only the Beta irieger has is configured that way)

yes, we tried to capture an image, it worked with the command for the alpha (as in the wiki)

the one given above should swap out colors nicely

I don't think that is possible with a matrix is it?

http://www.arri.com/mobile/amirapg/images/on_set/exposure_and_focus_check_options.jpg

i.e. if you map (via matrix) everything to grey and then use the gamma LUTs to create the specific colors

Yes we'd need a shaper LUT to do the mapping.

That's not a big deal.

Has anyone been fuddling with the PL?

Fabric of spacetime warping

the space-time warping? probably

The FPGA fabric weave.

what do you want me to weave? :)

Bertl: I'm just wondering if anyone has been doing the tweaking on the PL registers to get the dynamic range capture into the zone desired for a closer-to-final format.

I guess the current state we have with irieger's settings is quite good already

Bertl: irieger's tests weren't using the piecewise linear however were they?

not as far as I know

EI index?

hi Bertl

got a question about using some different sensors for scientific purposes

http://www.fairchildimaging.com/catalog/focal-plane-arrays/scmos/cis2521

do you have an url for the full datasheet?

we are in touch with BAE fairchild and might adopt their sensors in the future

this sound promising

not perfect but acceptable for us

and the price was above 20k€

not necessarily for video, but the modularity and hackability is very important

e.g. an external trigger for syncing the camera with an experiment

ams acquires CMOSIS, a leading supplier of high-end area scan and miniature medical image sensors

so, it probably depends on how you define 'scientific'

sure

well, we plan to use it for HDR

is there a way to get the overlay as a framebuffer device running?

parasew_: probably, but it would be rather slow

because you need to write four pixels for each pixel and at very distant locations

because the live view uses a quad buffer system

can you let the fpga mirror the buffers?

parasew_: not sure what you mean

Bertl: Hooligan in the middle is a problem.

is it possible to let the fpga mirror one buffer to the others, so you just have to write in one buffer for making it faster

Bertl: Were you there too?

parasew_: possible, yes, but probably not very smart

davidak is asking when the case will be finished

troy_s: well, the problem is/was that he was not authorized to say anything about the camera and he was always speaking of "their decisions" and "their developments" ... well, you get the idea :)

irieger: Are your tweaked registers using the piecewise linear knees? What was the overall latitude?

they do not change the exposure or utilize the piecewise linear stuff yet

Most painful pinch point was that interviewer.

which most likely was without HDR

Are we talking about the same thing?

PWLC

i.e. the piecewise linear stuff for example

I cringe when I read HDR

the problem is that there are two different 'HDR' modes

Need refreshing. Explain? One has that two / three pass thing with temporal nasty

The other one is like that goofy R3D HDR mode

Which is fundamentally broken and useless unless you are hacking your way around something.

Knees are the most logical

Without the lovely temporal artifacting.

Sure. One works. The other is goofy. ;)

troy_s: and while the artefacts will be more subtle and evenly distributed, there will still be temporal artefacts in the PWL mode

parasew_: which would add a lot of overhead and burn a hole in your Microzed

Can it be stochastic or is it just uniform?

well, think moving grate, where the "early" exposure falls on dark areas and the "late" exposure on light ones, or vice versa

so I'd say there is some testing required to evaluate the "quality"

(Where "usual" and "correct" would be defined by the existing learned aesthetic of course, aka "film")

for example, we haven't bothered (yet) to allow adjustments to the shutter angle

Bertl: but the arm core is dedicated for controlling ourposes, isnit ist?

Bertl: and a raspberry pi can also render a few controls with gtk smothley

Bertl: Well again, aesthetics are emergent so the 180 degree is a direct byproduct of 100 years of cinema.

parasew: At the point you say GTK you have probably tuned out a large chunk of folks that were listening. ;)

(on the no-brainer :)

Bertl: Have you seen this?

https://github.com/hpd/OpenColorIO-Configs/tree/master/aces_1.0.1/python/aces_ocio/colorspaces

so that means that the ArriRaw is quite cooked (to LogC) then

Absolutely.

bakes linear

I can't see it.

nothing we can't do as well once we have all the details measured/calculated

Yep.

With less secret saucism as say, Sony.

I'm interested to see if the ArriRaw stores linear

They get 14 stops of linear useful.

With no real marketing-ese

(which sounds a little over the top to be honest)

That's my point...

15000:1

so we can asume some kind of "HDR" mode doing the heavy lifting

I mean what is your guess?

We have to remember that the "bulk" of the image on transfer curves lives in a linear toe much like the 709 / sRGB encode

so perhaps a shallow curve up to a designated highlight range

(that highlight transfer is huge obviously to retain some details in the head range and not have your image end up looking like poop)

They _never_ do the patented "rat piss" on skintone

not even with custom LUTs? :)

Nikon's are at least as bad.

Oh no rat piss on Arri

Rat Pissâ„¢

Arri again does pretty damn amazing imaging engineering

Canon has very, very little penetration in terms of shooting.

I believe (well I know) Transparent uses the C series

(Which they tend to be quite popular)

EPK = Electronic Press Kit?

The behind the scenes folks.

Anyways, that 14 stops is why I'm keen to see the PWLC up and moving.

(where logically we'd map the middle grey for a given EI to 0.18, plus the offset)

Yes. I know he was talking about finding time to futz with it.

Where the toe probably covers 7 stops down from 0.18

(or 6 if the estimated latitude is 12 overall)

hey intracube!

troy_s: ate too much and hardly moved :)

*break

intracube: Fsck you and your DNG.

troy_s: ooh, where?

me only saw download sequence of the confetti

I think there was another raw dump somewhere.

seq12 has some in the root, not sure what that seq is.

This has some seqs http://files.apertus.org/AXIOM-Beta/snapshots/BetaRawTests/

those are a sequence of raw12 files

ApertusRaw.

yes, the unmodified sensor data dump

Yes; Always need a junk and useless format.

it is??

:)

we should definitely add some PNGs :)

Yes. PNGs and DNGs! MUST MUSTMUST

TIFFs are so old fashioned

Lulz.

intracube: You can turn that into a bash script pretty easily

just add #!/bin/bash

yep

if you pass the image in at the command line, yep

The good news is that you can be certain there isn't some SmartFsckingSoftwareâ„¢ mangling of your data values.

Just a raw dump to sRGB (or whatever your display of choice happens to be)

intracube: You saw the stanzas I posted for the conversion matrices?

like any good unix tool, so you can get rid of the name specific part

troy_s: nope

intracube: Let me see if I can find it. Like a buffoon I didn't start a git branch and instead edited the build installed config.

are the 3d print files for the beta online somewhere? for the enclosure?

http://www.pasteall.org/62722

(The description may not be up to date as I am often sloppy with the description when I am flailing with a transform)

I just need to insert into datafiles/colormanagement/config.ocio

then load the tif output from the imagemagick

cool

intracube: It's a junk format.

there is no final design yet

for enclosure

se6astian: Is it just me or does Phabricator not post notifications?

troy_s: you are right I also did not get any notifications recently - will check

all files are on github

se6astian: I haven't gotten any since the beginning.

well then you probably never enabled notifications :)

I've checked sixteen dozen times

But also reasonably sure I have set everything at my end.

se6astian: I'll take tips however.

I just got a phabricator notification of your change

se6astian: Do me a favor and update it for me to see if I can get a notification now?

nothing.

thanks.

what do these settings say: https://lab.apertus.org/settings/panel/emailpreferences/

se6astian: Yep.

Not in spam either.

I suspect due to the fact that I joined during the Precambrian era that perhaps the pipes were not working.

Not sure.

se6astian: HA. Got them now.

WTF.

I got your email to Gabe

oh, thats not from the lab :)

Can someone nuke my account?

I'll re-add and re-link perhaps?

not sure if we can relink the accounts...

It's just a junk amateur hour approach that is worse than awful.

It is enough that if I were to discover that as an outside audience member that I'd skip out and write off the whole project as amateur hour.

time for going extremely to bed!

good night :P

Well hell. No matter what I do I can't get email sent to me. I've added two more emails, different providers, no email comes from Phabricator.

philippej is maintaining phabricator, so it's probably best to contact him with problems