#apertus IRC Channel Logs

can anyone here help me decide whether i should help with your "gamma" versus continue on my own?

so... any takers? can anyone discuss the status of the "gamma" camera effort with me?

the current focus is on the Beta camera. I think plans are to ship it in mid 2015

phobos: my 2cents: it's more of a philosophical question, you should ask yourself!

if yes, joining the team and helping them the way you can is best

i have supported open-source before, sure.

depending on the philosophies and inclinations of those involved.

BTW, what is the time where most of these folks are? 3:40am?

yes. i was looking at the cmosis sensors (12mp and 20mp), so that much is similar.

There are at least two folks that frequent here making cameras outside the project.

One is a stills camera.

because robotics needs to look at one frame, then immediately control physical manipulators to interact with what the camera sees.

phobos: Austria and central Europe, so 6:40am

morning troy_s

phobos: So not stills, but robotics?

definitely not stills for me.

phobos: Not sure how it would fit in, but reuse is certainly plausible from the imaging side.

phobos: I suspect Bertl_zZ would be able to give a much better picture of the situation as well as tips.

you know when he usually gets online?

Try in about five hours.

what is "flip to spline"?

okay, i never heard of "flip".

mostly what i'm planning to do in FPGA so far is mostly detection of edges and features (hot spots (in each color), cold spots (in each color), and etc).

which helps provide the PC enough information to guess how this frame is different from last, and make a good guess about where objects moved from frame to frame, and predict trajectories.

not sure, haven't looked into that. but off hand, i'd guess that would require more FPGA processing that may be possible.

i don't want to adopt a $20,000 FPGA.

shooting for $200 to $500 range FPGA.

well, i'll have to look into them more before i can comment.

not as much as a $20,000 FPGA can do. :-)

but... $20,000 is about 10x more than i hope the whole camera costs.

one problem is, you can't hold 2 or 3 whole 12mp or 20mp images inside an FPGA... at least not with moderate price FPGAs.

but... not so good for "whole image" much less "compare this frame with last" type work.

i guess one way to look at FPGAs is to say... a $500 FPGA can perform certain processes vastly more and faster than a $500 PC, but only those certain processes.

BTW, who has been mostly working with the image sensors?

the compression ratio sucks compared to lossy techniques, but it can at least "make the CF last longer" or "push more over 10Ge or USB3 or SATAIII per second".

but... i do get the impression apertus folks do value "no compression artifacts".

better to project on a 4k platform?

my focus is 4K to 5K sensors, and eventually 8K sensors.

and please define "better" here!

well, in this case i'm talking about cinema, which means to me "what the image looks like to a human being".

the compression ratio totally sucks compared to ANY lossy compression. typically it was about 20%.

the virtue of the compression technique is... how simple it is to implement in an FPGA to run at real time (compress as quickly as the pixels arrive from the image sensor).

Okay, as we are talking about cinema here: even after the DI process(where the raw capabilities are fully used), we anyway have to do heavy compression for the final dcp.

which gives all the compression artefacts end of the day. Am I missing anything?

since it is lossless, the final result is exactly what came off the image sensor. exactly, bit for bit.

if i understand your point (not sure), many image processing techniques work vastly better on uncompressed images.

but... maybe i misunderstand you.

my point about compression artefacts was: at somepoint during post production of cinema, you are doing the heavy compression

but my question is: how better would it be? as, its a pain to handle a terabyte of data at the end of one day shoot. is the quality worth the pain?

if i go watch a high-end movie at a movie theater with the most modern equipment, am i seeing an image that was uncompressed in the projector system?

nope you are watching heavily compressed image on the projector system

my personal interest in lossless compression was to move the data from camera to computer faster, without loss of information during that process, or during image processing on the PC.

sorry i can't remember what website that was any more.

morning Bertl :)

hello there.

the late night crowd said i need to chat with you Bertl.

oh, good that you can see that. saves my fingers.

so, let

as you already stated that FOSS/OH wouldn't be a problem for you, it seems to me that you might want to go for the AXIOM project (may it be Beta or Gamma)

(especially as you have been looking at identical sensor options)

yes, it looks plausible, especially the gamma. but i have a few questions just to get my head in the right place.

well, some of this is questions, some is just throwing ideas out so we can brainstorm to a solution.

i tend to prefer to put as much functionality as i can in the smallest volume i can (with the least number of connectors, etc).

however, for development and testing, sometimes a modular approach is easier, and a more integrated product can be created after the fact.

i was looking, for example, at the 4-or-8 core 64-bit AMD ARM Soc chip.

so the sensor/interface board is about 60x60mm

in the beta? and you want the same for gamma?

but note: we are currently working on the Beta, so that is something we are designing right now, while the Gamma is more a vision

from the time-frame diagram, it looks like the beta will be done in 5 or 6 months. so the design must be done, or close.

you'll be done in a couple months?

I just returned from Mexico giving a talk at the TAG event about building the AXIOM Alpha from scratch in six months :)

that's fine

my point with the Seattle chip, for example, is that you can have multiple outputs for SATAIII, multiple outputs for 10Ge, multiple outputs for other I/O standards and who knows what else.... all on one PCB.

however, 60mm square is a bit smaller than i was thinking about before i looked at your project, so the abundance of connectors might just not work on such a tiny PCB.

(which would be there in the Parallella setup)

http://www.parallella.org/board/

they are connected to the FPGA

correct

sorry, start that previous sentence with "now, my..."

but there is no reason why you couldn't use an Altera FPGA as well

4 Multi Gigabit Tranceivers

and the hardened arm cores simplify testing

it is in their interest... to suck people in.

while the MicroZed is about 250 USD :)

oh, sorry. some of the development boards were like $180.

yes.

careful, we are using the MicroZed in the Beta design

so it would be a $1800 price difference for the Beta

comradekingu: probably

but... what does the development board have to do with the beta? you actually put a Xilinx development board INTO the camera?

challenge accepted

phobos: the AXIOM Beta is designed for developers and early adopters

but... i must say... i would make ALL my designs based upon what is best (features and price) for the final product, not the development process.

except... i don't have enough savings to ever create an ASIC for the project. :-(

yeah, that's what it looked like.

Gamma = professional end user equippment

unless you really haven't started. but even then, i don't like stepping on toes.

unless... i have a totally wrong idea from the website.

experimentation with the camera itself

but of course, we will also use it to improve on the Gamma design

we are easily convinced by good arguments and we have no problem adjusting our designs if there is a good reason for it

we do not plan to satisfy every concept and idea brought up here, but we will definitely look into it

phobos: judging from what you want to do, you might be interested in helping/working on the Beta Interface Board, while considering adding your own 'Beta Board' design with one of those AMD chips on it

i should probably ask about how data gets shipped around (typically). recorded onto internal flash then transmitted? stored on n * CF which are then removed and inserted into a PC. or... oh, now i remember some odd connectors on the beta.

the connectors are to the Interface and Sensor Board

http://vserver.13thfloor.at/Stuff/AXIOM/BETA/axiom_beta_sensor_cmv12000_v0.9_all.png

you might also look at the Beta Shield connectors, which would not affect you in this case, but you could adopt that interface as well

regarding data flow: no, we do not plan to store it on CF

allan created T145: Rewrite EULA for forum registration. http://lab.apertus.org/T145

hey g3gg0! how's going?

yeah, the beta has 3x HDMI. that's an interface i haven't worked with, and don't know what interface chips are available for (or FPGA IP).

do you expect most customers will want (primarily or only) CF storage for the gamma? or not?

do you envision a default, or every option is an interchangable module?

but I guess it will be a very popular one :)

though there's no requirement to exactly center the sensor of the PCB stack.

for the gamma, we haven't decided yet on the exact size, but it would make sense in the 60x60mm area

we will see when we get there :)

and, as i understand it, you already have two pretty large connectors between the PCBs.

phobos: you do not need to decide for or against the Beta, just decide if you like to hang around and more importantly if you like to share your ideas and concerns

not sure about that, of course.

but product development is what i do.

no problem there ... if product development and making big bucks is all you care about, then so be it ... most likely the Beta will not fit your goals there though :)

well, big bucks is never my goal, i have other reasons to get this stuff done. but i do want to at least earn back my time spent.

nonetheless, i don't see why open-source won't work in a hardware project, and still leave room to sell differentiated physical products and make some money.

i haven't done open-hardware before though, just open-source software, so... probably i need to make sure there are no "issues".

there is no viral component in the Cern OHL we are using, if you are referring to that

like, if we get gamma working, and i take design aspects, layout new PCBs and design a new case... do my PCBs and case become free for anyone else to make?

sure does.

no, your designs do not automatically become free, although I would hope that you open them up to the public as well

probably some or most. but maybe i'd add some image recognition firmware for robotics and create some integrated (not modular) robotics-optimized cameras.

while i can imagine that very likely nobody would copy them, and so i could sell and make some payback, there's no guarantee if my extra firmware automatically becomes freely available (and my case designs, etc).

i would, of course, know that everything i did to help create gamma was totally open.

one thing i developed a few years ago was a lossless image compression technique, to reduce storage requirements and transmission rates (for robotics).

i already opened that up to the public, though i have no idea how many people picked up on that.

if it helps gamma (and/or beta), that's great.

sadly, the compression ratio is terrible compared to lossy techniques.

no, but i can send something to you.

i called it "delta compression", because the basic idea is to store a smaller "delta" value for each pixel instead of the absolute value of the pixel intensity.

the compression ratio sucks, but it is mind-numbingly simple to implement in FPGA (in real time as the pixels enter the FPGA).

did i already send this to you in the past? hahaha.

in my case, what it did was this. for each 12-bit pixel, if the change in intensity was +/- 119 from the previous value (of same pixel color), then just save the 8-bit delta (plus an offset to make the range 0x10 to 0xFD).

otherwise you have to send 16-bits for the pixel, 4-bits of zero in the upper nybble, and the full 12-bit pixel value in the low 12-bits.

it only takes the CPU on modern PCs a few machine instructions per pixel to decompress.

you sent an email as 'Max' to the team, I just looked it up

oh, the recent message? i thought that didn't get through.

can i send a PDF attachment?

okay, i'll do that in the next day or so.

regarding email: it got through but it wasn't answered yet as far as I can tell

back when i invented this, i got a variety of uncompressed images and compressed and decompressed them to test my code and compression ratios, but i haven't done anything since.

it really is that simple.

okay :)

I can send you a copy :)

if anyone wants help putting the compression part into your FPGA, they should contact me. if someone needs C code to decompress, i can write that in a few minutes.

forget that little detail, and it anti-compresses! hahaha.

i don't need a copy unless you think i do.

so, one maybe interesting area for you might be the Beta Interface board

and it is designed to create a common sensor independant interface to the main board

you want to have a sensor independent interface to the main board. presumably you don't mean it has a fixed number of channels (unless that number is a maximum, say, 64 channels).

and what is on the "main board"? circuits to send the data out through those 3 HDMI connectors?

so 64 data and 16 clocks.

most sensors communicate with 300-600MHz

no, but most sensors we have been looking at match the interface

we do not expect all future sensors to work with it, but most LVDS based sensors will

and the KAC 12040

okay, i've only looked at the CMV12000 and CMV20000, so i don't know those others yet.

I will upload an interface diagram soon (probably tonight) which will explain the interconnections better

you could put a peltier behind the sensor, but IMHO it's better/easier to put it on the side

there is a metal plate planned covering all the front of the sensor board

have some kind of liquid-filled pipe to the sensor?

okay, yeah.

is there room in the gamma to put the peltier beside rather than behind?

no fixed sizes for the Gamma yet, but check with se6astian|away (when he comes back), he has all the data about the "current" design

yes, for the Beta we will investigate different cooling options

(the same place might as well be used for a peltier with heat sink)

no desire to keep it short for the Gamma

the professional cinema movie folks do not really care that much about small

is the small width and height considered important too? i just wonder about all those 3 directions, what people think about making them bigger (or smaller).

did somebody have a big brainstorming session about all that, somewhere along the line?

we have brainstorming sessions all the time, mostly here on the channel

naturally

this just seems like one of those cases (pun) where the ergonomic considerations are pushing in the opposite direction as "electronics efficiency". do you feel that's true?

I think something like 60x150 would be an option if there is a good reason for it

the problem I see with long, small PCBs is that they tend to have many long traces covering most of the PCB area

yes to that too.

yeah :)

yes, no problem there as I said

there is actually a good reason for making it taller

hmmmm... this really is tough.

http://vserver.13thfloor.at/Stuff/AXIOM/BETA/axiom_beta_sensor_cmv12000_v0.9_all.png (the measurements are around the PCB)

you mean they want the centerline of the optical system to be a certain distance above the base of the camera (that attaches to the tripod top plate)?

to match other equippment usually rigged up around the camera

say what? you eurogeeks are working in inches? seriously? hahahaha :-o

kind of the result of electronic parts and devices still using both

take the sensor, it is a µPGA with 1.27mm pin distance :)

no, not at all

and it seems to be sufficient for the Beta

google

case site:irc.apertus.org

like: case site:irc.apertus.org ?

okay.

(you might want to search there as well)

yes, there is a development mailing list (and some others as well) on google

IRC is where you are now (Internet Relay Chat)

https://www.apertus.org/mailinglists

right, so being a techie, i want to be on *email address removed* .

IRC is definitely the main place for communication nowadays

tasks, wishes and collections of thought go to "the lab" or on the wiki

and when you said you were going to upload an interface diagram, where will that appear?

so let's say i was going to write some code for the lossless compression algorithm. is this labs where that should go?

but a design or explanation or just idea would best be handled on the lab or in the wiki

i suppose i should make a confession. my previous open-source experience was releasing competed working software i had already completed. so i'm feeling a bit overwhelmed at how much stuff there is in many places in an open-project like this!

maybe it will all feel normal in a month.

(like I already did with a number of links :)

Not this project mind you a different one. Translator sends Japanese and English back and forth basically. D:

Also, in any case… your going to like this. I need to do Mocap for a scene… yay… literally like… maybe 5 second part of a clip. Fantastic.

Although, im probably way out of my depth.

well, English is quite common for technical folks, but I can imagine that being a problem

Sorry about the other post, that was for troy we were discussing compositing and vfx XD

no problem

There was a program, someone linked me. An irc client that runs off server. You connect to the server instance and can access it anywhere without logging off and logging back in type thing. Anybody know what that might be?

Hah open for suggestions on the best one?

ahhh ok

a friend of mine is using miau very happily

dircproxy, --- I guess some clients like irssi and possibly weechat can do such proxying as well.

what client you use to connect doesn't matter

hmmmm

Well yeah just switching between them or switching to mobile I dont want like two instances of my username popping up or continous connect disconnects. You know… courtesy..

oh ok

Weechat I think thats the one.

m ok

Ah wonder if i can install it on my webserver hmmmm

Rebelj12a: Quassel

back now ...

Bertl: Greets Herb

fine, thanks! and you?

:)

currently on the Interface Board and the basic interface to the Beta Board

Or the data output bits?

Right.

(and probably for a bunch more :)

yes kind of, the interface board has up to 80 LVDS connections plus up to 6 different voltages to the sensor board

the interface board will carry a low power FPGA which processes the sensor data and creates a structured stream of data

hehe

(Debayer versus order/structure/protocol)

if it works well, it will do pixel reordering and checksumming

as well as bandwidth management

Another FPGA?

CPLD or FPGA yes (on the interface board)

Sebs working in sync or on hardware?

That is what I expected.

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

the rods typically need a bit of space to be fixed under the lens base themselves

s/lens base/camera base/?

okay, thanks!

these pats typically look like this

*parts

kontrakatze created T146: Reorganisation of channels for communication. http://lab.apertus.org/T146

troy_s: On the hundreds of gigs I have only seen the 15mm/60mm appart rods in action so far

but no accessories for it

off for a nap ... bbl

sebastian closed T8: Research Sony E mount patents as "Resolved". http://lab.apertus.org/T8

Im guessing fairly difficult

Blast, gotta stay off hackaday… the stuff people make there gives me too many ideas.

https://hackaday.io/project/1552-lofi saved

Maglev, slider… … for fast stabile pans? Ok enough hackaday… for a day… too much...

Rebelj12a: the process is fairly straightforward once you discover what the parts are

danieel Yeah looking at that, Its a firewire isight camera. So mac closed im sure… old school one heats up pretty good too but the firewire interface simply wont work. Well unless arduino has firewire libraries, regardless of having a plug around on an old motherboard im sure, but still… direct sensor access would be nice for a better quality image in theory.

Ohh I just saw it and thought it was pretty cool.

do you know the model/year?

probably it has a model number

is it this? http://jjhale.com/blog/2010/03/irsight-converting-isight-webcam-to-ir-webcam/

A1023

probably around 2004

if you are into oldschool analog, try it

yeah

Maybe ill just take it out and stick it in my 8mm movie cam XD

must go resting.. gn

Well found linux isight drivers for firewire thats a start right...

Long debated this. Taking a monitor like the high resolution ipad, seeing If i can get the wacom to register in one case so I can have a real time drawing monitor. That would be nice.

depends on the circuit board :)

I dont know, its for a film scanner… but its not optical the board is covered so im guessing light.

Im guessing a light of some sort

Bah

Theres a backwards R and U combined logo

Pan 301

FM1-0598/FM1-3650

backwards R and U is not a company

Ugh this is why I like standards D:

oh….

http://ul.com/corporate/marks/ul-listing-and-classification-marks/downloadable-ul-marks/

hmm

hey hey now “supposed� to be

Or that may just be the pcb assembly D: