#apertus IRC Channel Logs

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

hi Francky

so Berl did you use this week end to think about the pic interface ? :)

hi

hey fadro!

ca va merci et toi ?

come on !

let's hear ...

well i write a smal paper here:

Francky : En forme après le 1er we BBQ de l'année!!

(which makes sense as the sensor manufacturers often give working voltage ranges and not a specific voltage)

and of course, the power supply unit is not on the sensor board, as I already explained, to keep away heat and avoid duplication of the power management system on each and every sensor board

Yes, right, Over and under voltage are already on the board. The idea here was to say the this voltage values can still in the eeprom , and at each power up, the power management unit look at waht voltage applies and do it.

it also has a separate probe input to allow for voltage verification _before_ the sensor is powered up

the eeprom provides the voltage ranges in some way (either via identification or directly as values stored in the eeprom)

(selecting a specific voltage (user decision)

*voltages

in case anything is over/under limits, the power management system immediately shuts down the entire sensor and logs a failure

so not very different from your document :)

excellent!

I just write a small paper as the basis for discussion...

gotta go

ouf...ok, i'm done...3D representations are not perfect but it allows to understand the overall contruction (i hope!)...

Here it is:

I think you mean "beta board" where you write "power board"

what page for the "suspicious power board" ?

Yes you are right! beta board

There is an exception for the Beta (on the right side). It also have some PCI style connectors, but these ones are intended to fed the IO lines for further extension boards.

you also mention a shift for the PicoZed, which would be about 1" at least

also introducing misalignment between the boards, which means they cannot be screwed together easily

something like this:

Well, concerning the space on each side, since the power board (the most populated one), is now in the back, its allow you to reduce the size of the beta and the IF board, which do not lead to adding space on each side

Furthermore, board have naturally strong mechanical links because of the construction ( the power backplane).

here are the points I dislike in the design:

(i.e. they have to have the PCIe connector and connect from the side)

- with a proper power connector, we also add a lot of space to the side in this design

s/power plane/power backplane/

OK, well let me answer:

Then I propose PCI connector style, but of course we can easily find connector wich are not so high.

which would not allow to plug in a module

the one labeled "IO extension (actual IO shield)

okay, how should that work connection wise?

to which side?

so it is to the external side, to allow easy access for these IO shield extension

if they have connections on the side, they all need to be on the same side, and plugging them in is not trivial (from the side)

it provides good power distribution, there we completely agree

(remeber, our current power board is already crowded

the direct output for MGT/HS is IMHO still an illusion, because even if you shift everything so far that it gets out of the way, you still have to conenct in the wrong direction

Well, i represent big power connectors on the power board, but of course, they will not be so big at the end. Then, the backplane is as large as can be the current one. Only the shape is different. And futhermore, from what i understand the schematic of the power board will be completlly reworked.

and with a reduce stackup, the total width of the power board would be 35mm or so?

it is trickier than it looks

yes, pci will not be the best choice, but as i said, that's pci style, not pci itself, so we can find more adapted connector for this. And yes you are right, there will be less space on this power board than on the current one. But as previously said, power board will be reworked, and new "optimal surface component" can be choosen (more than one regulator per chip, ... Furthermore, all monitoring can be placed on each respctive board.

and you still have to find those PCI style connectors which allow a tight packing

Well concerning the modules : On this design they are on the right with a direct acces, so you don't habe anything to disassemble to change one. And from what i understand, this is not the case on the current design. On the current, you have to disassemble the µZ and the power board to access the IO shield module

the I/O shield is just plugged into the PCIe connector

So there is something unclear to me:

OK. but here we are speaking about the user extention IO module, not the shield module righ?

where probably only one shield will be populated by default with a PIC32 module

the "shields" are plug on like for the arduino (thus the name)

(in the stackup, only one is drawn)

And furthermore what is the interest for putting the PIC32 on a shield? Shield are optionnal removable part, but the PIC32 will be in charge of the power management so a muqst be there functionnality?

the plug-in modules just need to be un-plugged and new ones plugged into the slot

for the shields, on the skeleton setup (for developers) you just remove the existing shield and plug on a different one

for the PIC32 "now optional", yes and no, last week we had a longer discussion and we came to the conclusion that

in case the power management features are not needed/wanted

OK, i just realize for the 2 shields board, they are connected on the front, so you plug it close to the IF bard...$

correct

So now i'll speak only for the next revision, not the early adopters one...

careful, don't mix up AXIOM Beta with AXIOM Gamma

As we previously said, the power management unit is in the heart of the system and can't be removed easily, so there in an interest to leave it on a board and not on an extension shield. Do you agree with that?

power management for the beta is central and not an extension in the current design

note that a power distribution board wouldn't be a problem per se

hmm?

the PIC has direct access to the power management though

yes, it _can_ do those things

Yes but arm cores are not connected to all voltages monitors and power supply control. Only the pic is from what i understand?

all the sensors will be on I2C busses, and the FPGA will also have access to those bus systems

even the IMU(s) can in theory be re-routed to the FPGA if there is no managing microcontroller

I'm a bit lost...So what is the PIC interest in this case??? Gather 10DOF sensor data? In this case, it can also be done by the arm, and your PIC is no longer needed..

yes, the main purpose of the microcontroller shield is to take over when we enter some kind of low power state and, if present, to take off some load from the arm cores

Well if PIC is on the shield, i don't understand the interest of the PIC except for the low power mode. And in the case of low power mode feature, a PIC32 is not requiered to achieve such simple functionnality.

it is a development kit and we want to allow for trying out a few things

or add their own kind of special remote control

it does not mean that we have to a) support the software side of all possible variations

if somebody (during development) decides to remove/replace it, s/he has to take care of the breakage

And if the purposes of PIC32 is collecting few data and low power management, a much smaller µC can be user...

*used

if we figure out that a way smaller µC is perfect for us, we simply change the shield and nothing else

I think you're again confusing the shields and the plugins

So plugins are the both cards on left side of the camera (pcie connectors) while shields are close the IF board and are in the camera enclose, right?

yes, the shiields are at the front, beside the interface board

(at a right angle, via PCIe)

So yes, i was speaking about the shield, and i still don't understand why you need a pic on it. From what i understand, shields are optional, Si why to put a critical function like low power mode on a shield. For example, the IMU sensor would have is place on a shield. It is monted only if requiered.

we might make it a full shield, but I doubt it

the main reason for putting the PIC32 on a shield is that if we put it on the Beta board, we can't easily test different microcontrollers and/or adjust the GPIO interfaces as we consider appropriate without redesigning the Beta board

in case we decide (at some point) that the PIC (or a smaller PIC or a different µC) is the perfect choice, we can make it part of the Beta board

So this mean that you xant

So this mean that you want to use the PIC as an IO extender at the end (by adjusting the GPIO interface)? And why do you want to test many µC? The µC choice is simply driven by the functionnity you plan, and that's it!

well, since you have a much better vision of the project than me, i imagine that you should have shaper answers than me! But from my point of view i don't see anything else for the µC to do than low power mode, collecting and managing power data. For the shield interface, it's hard to imagine all stuff people will do, so (i think) that the best is to provide enough io and throuput to it.

OK, so why is needed a PIC on the shield? If it is related to power management it is big and the shield may not be the best place. If you want to extend IO interface, use bigger FPGA rather than µC.

OK, so you plan the shield with a PIC for the tests purposes with the early beta HW, right?

b) we decide the PIC or whatever µC is the perfect choice, then we move it to the Beta board and eliminate the shield on this side

So when you say "flexible as well as usable for our purpose", you already konws the goal you are looking for, right?

OK, so you plan to send some camera to "early customers" to have a feedback?

specifically software developers and similar

OK, and you'll wait to have enough feedback informations from the community to make such choices, right?

we don't want to spend a year developing what we consider the perfect camera development kit, just to find out that we are wrong on so many levels :)

That right, engineer ideas are not always related to users expectations...

go ahead, no need to apologize :)

this is a possibility, but we hope that we

b) that we can use the space now occupied by the PIC shield in case we don't :)

hum, you mean to the other side of the beta board in case of failure?

i.e. the side where the plugin modules are

troy_s: we really don't know yet, as we only had a single voltage on the sensor (for each rail)

but there are indications that it might affect the nois created by the sensor

I guess it will be a trade off of sensitivity vs noise

troy_s: it might be, it might as well be something you need to tune on a per sensor instance basis

(Figure out the underlying axes)

it might have some relation to overclocking CPUs

Bertl: Darktable released a rather large post on highlight recovery

If you are at all interested in that junk

yes, sure and I guess folks here might be interested as well, so go ahead, past an url

http://www.darktable.org/2015/03/color-reconstruction/

You are missing data

troy_s: Hello !

I prefer the statue before processing

wasn't there a different method discussed on the magiclantern forums that could actually restore usable detail in the highlights?

intracube: It is all guessing, and in this case, I suspect possibly guessy guessing. :)

I guess it's a difficult example as all 3 channels seem to clip at a similar point

you you can't exploit luma info in one of the unclipped channels

Luminance is the Y in XYZ.

RGB distributes Y across (due to non orthogonal nature of XYZ) all three.

(In a purely display referred domain, if normalized to 1.0, you can nail it.)

good evening

Yes.

As in, what is in that reflection? Sky. Sun. Etc.

troy_s: there is some real data there in the arm highlights: http://pasteall.org/pic/show.php?id=85026

intracube: The moment you guess missing values like that the phrase “real data” goes out the window.

indeed, and the water to the left takes on a greenish tinge :P

intracube: I was _just_ discussing this via email with someone who is refining their HDR techniques

I basically said that HR is the bane of HDR work, so turn it off.

Yes. Guess what the fsck a value is.

There are many ways.

it gets even trickier, as there is usually no way to know that it is missing :)

Bertl: See above where I said “Not great” :)

intracube: dcraw has four. I am sure there are hundreds.

given that you have a bad sensel, we can talk about "missing" but otherwise, how to define a "missing" value?

Bertl: Rather easy to discuss “missing”

so let's assume we have a sensor with 8bit output, it gives you values 0-255 for each sensel, let's further assume a bayer pattern

let's say the sensor is perfect, i.e. no bad pixels

how to decide what pixels are e.g. overexposed

Well any that are clipped or into the junk data CMV12000 range. :)

Although that gets muddy as given the sensor is most accurately modeled with a 3D LUT, near the edges of the latitude range it gets wonky.

2 bits?

Or what was it?

Thats what I am saying

Always.

(just saying here, not arguing :)

Which sort of ignores 100 years of grading.

The default display referred transform is a hard clip at 1.0

Architectural rendering of course looks completely wrong

by adjusting their damn scene values

So instead of say, scaling the black from a given value to zero, and selecting a scene referred value of say, 131.4 to white

They mangle their scene data

Same goes for photography.

(Or output referred if you want a more generic term.)

anyway, off for a nap ... bbl

se6astian: A few changes

se6astian: There. I I think that hints at the cones in the eye better.

great :)

back now ...

Re

I saw some discutions about architecture and interface today

I am here/around, yes

I think because you answer every time the same questions… :)

Except in your mind :)

but it would be good if somebody could pick up the expanations and put them together in written form (wiki, documentation, etc)

fadro, not that I know of

For my understanding : there is an official team and some contributors in apertus right?

where the transition from contributor to team is a rather smooth one :)

Have a good night

and yes, fadro might be doing the documentation

great!

time for bed

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