#apertus IRC Channel Logs

Would be interesting comparing the latitudes with knees. I suspect they are using knees too, otherwise a limit of 7 odd stops seems... Underwhelming.

Bertl: Was the data at all reliable with a knee in that region?

Yep. Just a custom LUT for linearization.

Bertl: The profiles you and I hammered on had the LUTs.

what I mean is, if you want to know what a camera/sensor uses, you can shoot a very clean and evenly lit set of let's say 128 grey gradients and calculate the applied curves from that, even when they were 'corrected' with a LUT :)

I'd sort of expect to see noise right down to the darkest areas of the image, but this wasn't the case

anyone know why this is the case?

maybe I'm getting terminology mixed up somewhat

intracube: As in a double up scale?

so if it is common to say they are crushed, then so be it

I'm pretty sure the data was clipped on both ends, because of the limited range of the recording device

i.e. 12 bit after processing -> 8 bit recording

Bertl: so the 12 bit range wasn't remapped down to 8bit?

intracube: it was, but I'm pretty sure it was clipped during the process

Bertl: oh x2 :)

intracube: Usually the other way, but both are possible thanks to encoding / decoding.

hang on, I'll upload an example

the distribution around a given value should be gaussian

(requires localized histogram)

mxf loaded into blender's compositor and RGB curves to lift

I've massively increase exposure so highlights will be clipped way more than in the original

sure, no problem, I'm just curious what kind of information you expect the second snap to provide, which couldn't be concluded/derived better from the first one?

that's at least not clipped in the highlights :)

Bertl: PLR HDR is equivalent to superimposing 3 imagines with different exposures; and highlights in the first 2 may have been clipped; the info that is missing in the resulting superimposition is whether these first 2 were actually clipped or not

voltages and exposures

Bertl: suppose this spark enters in the last very moment to a pixel which was not clipped

correct

Bertl: we can not tell if this 95% resulted from a less bright spot which was there all the time and caused the first 2 images to clip

yes, I agree

but if you take another snap after the HDR snap/readout, that fast moving bright spark will end up in another pixel

Bertl: my thinking was - make the extra frame with very fast shutter, say 1/10'000; make an assumption that spark is not moving too fast; then on the new frame it will be approximately at the same location as during the last moments of the main exposure

Bertl: but if the spark on the extra frame is relatively dark - then there was clipping

Bertl: and immediately adjucent to one end of this clipped area there is the spark

it would be easier/simpler to run 3 exposures instead of the HDR one and combine the data afterwards

Bertl: that was my earlier idea: do 3 exposures

Bertl: with that info I hope post processing has got a much better chance of guessing how to correct artifacts

maybe, maybe not

Bertl: another crazy idea. Suppose we're happy with 1 knee point. Suppose we make 3 exposures however. Suppose exposure A is 1/5000, exposure B is 1/100, exposure C is 1/5000

Bertl: then we make a mask; the mask allows modification only where B was clipped

regardless of the processing, I'd suggest to reduce that to A and B

because A1,B1,A2,B2,A3,B3 will allow the same with less data and better exposures

Bertl: yeah, or maybe that

Bertl: maybe that's nothing new to you - I'm happy anyway

Bertl: the main idea here is that when you do it in camera you end up with more info for post processing to make its guesses; what are the probs?

and secondly the readout time might be a limiting factor for very short exposures

so the two exposures need to be 70 microseconds apart

Bertl: if my reading of the PDF is correct that's not a problem?

yes, but that creates noise

Bertl: aha - so reding out during exposure creates extra noise

or the other way round, i.e. exposing creates extra noise on the readout :)

we didn't investigate it further, but it might complicate things

depends on the data and what you consider long :)

I see. Around 1/300 is definitely long for that kind of magic

or can any bit be wrong?

but it might be perfectly compensateable with proper settings

it lets you guess if there was clipping or not during main exposure

Thank you for spending lots of your valuable time discussin my clueless ideas :) G'night

and it is quite interesting to hear what folks plan to do with the Beta, so I'm really looking forward to the results

btw, i pick up that gn8 saying and leave my self :)

cya

perhaps you've seen my chat with Alex - there I suggested simply doing 4 or 6 frames in succession and adding them together; this is expected to have some positive effect on DR - though not as much as I naively hoped for

why half the iso?

so to get noise back to where it was we can make the picture 2 times darker - hence half the ISO

hmm ... I'd presume you scale the gain (if possible) to 4 times the range

well I'm pretty lost on this - but that's another idea that I wanted to make sure you're aware of :)

but you are also getting four times the range when simply adding up

so I'd rather think that you would be able to reduce the noise this way

well I've circulated the idea to you - that is all I can do anyway :)

Bertl?

ha ha :) possibly so

so, I think the main advantage AXIOM has over all the other cameras out there is that everybody can test new approaches

which makes it possible to test a huge amount of different ideas in parallell

you get all the cool toys! :)

both, yes

and in camera, only the "fast" algorithms would work in realtime?

probably

the analog gain is like iso? double gain is like double iso is like 1 stop more?

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

good morning

bbs

sers bertl :)

hi everyone !

will there be apertus at photokina?

wellllll i stayed up late, slept late and while waking up, i realized i eat a lot of unhealthy stuff lately, so i will fast for a day and maybe trink some purification teas :) digging trough all the papers i wrote the last day while my appointments and generating todo lists from it and doing em :) and i ve to clean my house, as i ve had no time and energy the last three or four days to do it... and i should mow the lawn and do some

only very few cinema/dslr blogs/news sites have mentioned apertus beta. on the contrary digital bolex kickstarter campaign was mentioned to almost all of them many times, not just a post

yes that would help

yeah; se6astian, do you need any more info about the test images?

i think AXIOM Alpha Colorgraded Sample Footage is not the best it can be. actually that last scenes are a bit disappointing in terms of DR

also i believe you present the goals of the project better

alexML_: will hopefully have time to do them tomorrow

thats a very very cheap alexa

and the (not so distant) future goal is to find a way to unlock the whole potential of the sensor optimized slope hdr way to record 4k 300fps to external etc etc

sensor aided stabilization...

there are two options for 4k hdmi output, a hdmi 1.3 shield with 4 links, or one hdmi 2.0 link

once they got the shields up and running

and there is no solution for raw recording yet, but a lot of space for development :)

will there be hdmi 2?

you might need to reload the page completely

but dont promise too much

i might be totally mistaken as well, but asfaik its either 4 hdmi 1.3 links or one hdmi 2.0 link on the shield

"a really affordable alexa with lots of room for experimentation"

its TINY

its a fetus at all :D

you can always put it in a bigger enclosure, the countrary being impossible :-)

if you start big, you can only shrink

s/than /then

hope im wrong

maybe it should be announced as camera and not cinema/movie camera

there still time to correct some things and make some things clear

the main is what will people have after they give you 2700euro and what they will be able to do with it

the update you did seems to be in the right direction

the area outside the 4k safe area?

the look around is basically if you record less than the sensor resolution then you're still able to see the area outside (where microphones come into the picture, etc) on the monitor

se6astian probably knows where all the raw data is

regarding HDMI 2.0: while that is possible, it is not really planned HDMI 1.4 already allows 4k at 30 FPS which should suffice

so it will be three hdmi 1.4 links?

either 3x FullHD (or slightly above) or one 1.4 with 4k

but as we have not seen any real world HDMI 2.0 (or 2.1 FWIW) recorder either, I do not think that it is a big deal

but as we already said, we do not like to promise features we are not 100% sure we can deliver

philippej2: please disable/remove the test contact form :)

aombk: I don't know the alexa specs and I don't think we want to compare the AXIOM to proprietary devices out there

but the least beta can do is very close to what alexa does

and alexa is considered by many the best choice available

i dont think you should call it alexa like ... first the dynamic range will (and this is to be tested) only be attained through HDR, and there's much other stuff to the alexa

i thought - hmm maybe if there was a page on the net with instructions on how to build the shoe box camera - maybe then he could run it

and perhaps that kind of an article could draw attention in other types oc media

its very interesting to watch other people work :)

anton__: go ahead, write one, all the data is available on either apertus.org or github

off for a nap now ... bbl

... 50 EUR ...

i mean if it would be theoretically possible for the beta

there is... but it's buried in a sub-forum: http://www.cinematography.com/index.php?showtopic=54929&page=2

a function to define what matrix should be read for achieving the 1080p signal is very desireable as well, as the nikon d4 got a similar function, where one can read "true" 1080p from the center of the sensor, which gives a lot more sharpness and makes the lens wider (crop factor)

derWalter: Most imaging apps provide for hot / dead pixel maps.

even some hidden firmware functions offer you that :)

where is the fun of dreaming, if the story ends after sentence one :D

derWalter: The problem can appear complex if you speculate. In the end though, it is missing data

derWalter: Only a few ways to “solve� that.

like the first published statement to the crowdfunding ended with: fingers crossed

back now ...

vlc doesnt work for me

I doubt I have any prores movs on my server :)

http://footage.apertus.org

IIRC, we reordered a few MOVs to have the index information at the beginning

nice

nope, it was an automated conversion, but IIRC, we left the old version there as well, so those where a .mov.<something> is present too should have been converted

se6astian: Might be worth mention that the triple HDMIs will offer independent LUT support on each.

Bertl: You said they would!

did I?

fact is, we do not know where the HDMI ports will be placed in the pipeline yet

so it sounds reasonable that we put one on the raw data, another on processed data and the third after combining the processed data with an overlay

but assuming that the FPGA has enough resources, three completely independant pipelines would be conceiveable as well

(As in the one that folks are using to look at the footage. I would doubt anyone would want to shoot without a basic LUT of some sort anyways, nor even a 1st use it.)

yes, for example

Bertl: Did you ever come up with a plan for the framelines?

The frame lines. The ability to pass custom frame lines for the EVF etc.

Bertl, so it is unlikely you will continue the automated conversion?

derWalter: Not exactly desirable.

aombk: ist there something (new) to convert?

troy_s: ah, well, either we manage that with the overlay or we do special line stuff like with the pong game if you remember

troy_s: we could go old-school for the frame lines on the beta

...gaffa tape :P

bertl, only one dir is converted. and one or two from other dirs

I swear I had them there.

Bertl: https://wiki.apertus.org/index.php?title=Frame_Lines

anyway, there are a lot of folks here who would love to join in this and similar effords I guess

okay, still could use some examples, maybe images of existing solutions or links to them

a dedicated chip, not to use the fpga

Bertl, if you find some spare time please convert the files in all the dirs in AXIOM Alpha footage/

derWalter: but you probably could put one on a shield

i want x264 shield

build one :)

nah

you build three and give one to me

Editorial stuffs. Dump it when you land the disk.

god dmmm.. rhyme i meant :D

aombk: the webm vp8 codec is as vhdl available....

this would be for TV work rather than film, but: http://www.videocopilot.net/blog/wp-content/uploads/2010/01/cut.jpg

the important part is what kind of markings are to be expected

so that we can think about keeping it pretty generic, but also efficient

IMO, as a minimum; black, white, transparent pixels

ha! 2 betas 3d setup and android phone with google cardboard vr would be great!

not a big problem per se

(or rather typically, and for good reason.)

But I get it that the processing can be an issue.

It's effectively two bitmasks really.

intracube: No. But Bertl was originally concerned about processing overhead for an image.

oh ok

Keep the processing down.

not sure how that would necessarily be any less compute intensive

I can understand pixel blending operations would be more difficult

we can generate them as part of the image pipeline (as we did for the entire graphics in the pong game)

the first approach requires careful design and limits the shapes and number of lines you can do but doesn't require much memory to actually describe the lines

because the overlay needs to be fetched pixel by pixel on every frame

troy_s: being able to adjust framing lines in camera menus on location would be nice I guess...

intracube: Well you have to remember that some folks want to adjust the marks to upper thirds too etc. Too many variations.

but a production would (should) decide well beforehand what their shooting requirements are and could design safe area images beforehand

intracube: Yep.

no, actually three files

Bertl: might something like this be possible with the first method: http://provideocoalition.com/images/uploads/sa00_hero_640.jpg

the camcat ones?

...although some people like rounded corners to the boxes...

aombk: T047 in garden flowers, the crowd funding video and the beta pitch

and that helps?

but yes, would be possible

yes

if you're shooting at night, then the white lines will be visible, etc

yep. I think I've seen some overlays that invert whatever pixel colour is behind them

otherwise grey scene will end up with grey lines

even ant pathes would be rather simple to do in the FPGA

for example a simple mask can easily be RLE encoded and so could fit into a very small memory block inside the FPGA, as long as it can be simply expanded during the frame construction, it wouldn't need any additional memory bandwidth

wouldn't inverting the overlay based on the content be compute intensive?

interesting

good night

Guys, where is the core Apertus team based?

se6astian and me, we are in Austria (nearby Vienna)

https://apertus.org/team