#apertus IRC Channel Logs

morning se6astian!

congrats!

(for others to get inspired)

Difficult even with the Google sheets

Some parts are out of stock, etc... At least I ordered the ZIFs in advance

usually you can use similar parts (for passive components)

True, I saw a few werenobly available from Farnell but not element14 America

we have the opposite issue :) some are from america only and not at Farnell :))

specifically on the power board and the sensor frontend

yes, for example you can drop the entire voltage check blocks from the sensor frontend (for now)

and there you only need to populate the circuits for the actual voltage rails in use

http://files.apertus.org/AXIOM-Beta/Beta%20Sensor%20Front%20End1.jpg

well, you could leave out the eeprom at the top left as well

you can also leave out the micro SD circuit (if you don't need it)

https://wiki.apertus.org/images/f/f4/BetaPowerBoard_0.18_TOP.jpg

Bertl: once i wanted to do a html/svg visualization of boards.. this required/optional/dnp could be shown nicely with such a gui..

yes, and as components are tagged they can be filtered by that

does such tool exist?

for my next birthday (april 1) we can rewrite the debayering article: http://stargazerslounge.com/topic/166334-debayering-a-dslrs-bayer-matrix/ :))

Purple PCB prob

Oops

Http://imgur.com/gGWlr

Third times a charm http://m.imgur.com/gGWIr

Bertl: thanks for the pointer to minimal configs, may go with that for now

on the main board, you can leave out the shield connectors for now (they can easily be added lateron) and the piezo

Would like to have a spare cam and have it "debayered" :D

definitely hardware based implementation of the algorithm :)

Bertl: I head a great idea. Would be nice to be able to just output raw 12 bit data via HDMI and would be recordable with existing hardware. My idea was: Pack raw data into 1920x1080x3colorsx12bit

and 12bit requires deep color

Bertl: is that a problem with the HDMI controlers?

just did a small calculation how this would fit into 1920x1080 while on the road cause I liked the idea and there is already hardware able to capture 1080p50 / 1080p60 at 12 bit 444

So 60p is only possible with 8bit and 10/12 will require to go back to 30p?

also note that most recorders cannot capture 12bit 444

in raw or with some lossy codec?

Bertl: in 12bit 444 DPX so uncompressed "raw"

well, there are still some options left, I have some ideas which we will test in the near future

btw. I recently played with color matrix creation with our toolset which I currently test and look for optimization possiblities. Here is a test image: http://content.irieger.net/bm_colorchecker_srgb_tun.jpg

And on the linux laptop I'm currently on it looks quite worse than on my Macbook I have to say

;-)

Well, I will play with different optimizations. Our tools allow to throw in some parameter files to for example focus the optimization on skin tones etc.

(i.e. with compression in place)

for example, assuming that there is 422 recording at 60FPS, we can break down the raw image (at 30FPS) into two images RG and GB with a proper distribution

Bertl: well, most really cheap recorders can't do 60fps either ;-)

Definitely.

Yes. Just fear what prores will do to the raw image. And it will lose 2 bits

so if you have two recorders which can do that, then you might already have a raw recording solution with (almost) full size

Of course, that should work.

John_K: Full sensor is around 432 MByte/s I'd say

Right but for 1080 should be possible with minimal compression

So should be attainable with compression

John_K: The problem is: You have to do the bad stuff DSLRs do to get 1080p RAW or just take the inner 1080p frame of the sensor which is also kind of bad.

Sorry ~16px extra on all sides

Sorry, have to go afk, will look back later. (Note to myself: do a proper afk state like bertl/se6astian ...)

Hrm, true

Might be fun to play with at some point

gnight