Current Server Time: 14:01 (Central Europe)

#apertus IRC Channel Logs

2015/03/09

Timezone: UTC


23:16
Bertl
off to bed now .... have a good one everyone!
23:16
Bertl
changed nick to: Bertl_zZ
00:52
fsteinel
left the channel
00:52
fsteinel_
joined the channel
00:54
intracube
left the channel
00:57
intracube
joined the channel
01:14
intracube
left the channel
04:42
ItsMeLenny
joined the channel
06:03
Bertl_zZ
changed nick to: Bertl
06:03
Bertl
morning folks!
06:26
cbohnens|away
changed nick to: cbohnens
06:27
cbohnens
good morning
06:59
AnxiousGarlic
joined the channel
06:59
AnxiousGarlic
left the channel
07:36
MatthiasF
joined the channel
08:14
Jin|away
changed nick to: Jin^eLD
08:21
Francky
joined the channel
08:21
Francky
hi all
08:22
mars_
hi Francky
08:28
Bertl
hey Francky!
08:31
Francky
so Berl did you use this week end to think about the pic interface ? :)
08:32
Bertl
not much, I had a lot of other stuff to do
08:49
se6astian|away
changed nick to: se6astian
08:51
AnxiousGarlic
joined the channel
08:51
AnxiousGarlic
left the channel
08:52
se6astian
good day
08:54
fadro
joined the channel
08:55
fadro
hi guys
08:58
Francky
hi
08:59
fadro
Ca va Francky?
08:59
Bertl
hey fadro!
09:00
fadro
Hi Bertl, these 2 days off allow me a "putting all together" brainstorming...
09:00
Francky
ca va merci et toi ?
09:00
fadro
And I would like to share some with you!
09:01
Francky
come on !
09:01
fadro
1st is concerning the sensor board power architecture
09:02
Bertl
let's hear ...
09:03
fadro
Well to try to keep the best of the 2 worlds (remote power supply for sensor board with maximum security, when changing sensor board and avoid burnout risk),
09:03
fadro
well i write a smal paper here:
09:03
fadro
https://www.dropbox.com/s/rxlvl8co9fyg0b3/SensorBoard_PowerSeq.pdf?dl=0
09:04
fadro
Francky : En forme après le 1er we BBQ de l'année!!
09:05
Bertl
yep, looks like the current design, except that we allow "ranges" not just voltages
09:06
Bertl
(which makes sense as the sensor manufacturers often give working voltage ranges and not a specific voltage)
09:07
Bertl
also note that most sensors have at least 4 voltage rails, that's why we went for 6 with the idea to have 2 of them for high power and 4 for low power applications
09:09
Bertl
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
09:09
Bertl
note that the under/over voltage detection still happens on the sensor board, and is reported (both, not just the combination) back to the power management system
09:10
fadro
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.
09:10
Bertl
yes, that's the idea
09:10
Bertl
it also has a separate probe input to allow for voltage verification _before_ the sensor is powered up
09:11
fadro
Oh, that's what you have in mind for the voltage values in eeprom ?
09:12
Bertl
the eeprom provides the voltage ranges in some way (either via identification or directly as values stored in the eeprom)
09:12
Bertl
the power board adjusts the rails according to those ranges
09:12
Bertl
(selecting a specific voltage (user decision)
09:13
Bertl
the sensor board then approves the voltage via verification
09:13
Bertl
*voltages
09:13
Bertl
if everything is fine, the power management starts power sequencing on the sensor voltages
09:14
Bertl
in case anything is over/under limits, the power management system immediately shuts down the entire sensor and logs a failure
09:14
Bertl
that's the current plan/design
09:14
Bertl
so not very different from your document :)
09:15
fadro
Yes! I was not clear with the complete procedure. But it's look fine to me so.
09:15
Bertl
excellent!
09:18
fadro
I also think about the boards stackup we previously discuss. And since i begin to better understand your constraints and choice, i would like to propose you a slightly different stacking option..
09:19
fadro
I just write a small paper as the basis for discussion...
09:19
Bertl
okay
09:28
Francky
changed nick to: Francky|away
09:58
Andrej741
left the channel
10:08
se6astian
gotta go
10:09
se6astian
changed nick to: se6astian|away
10:22
fadro
ouf...ok, i'm done...3D representations are not perfect but it allows to understand the overall contruction (i hope!)...
10:23
fadro
Of course, it might be seen as a general concept which can be reworked again and again ...
10:23
fadro
Here it is:
10:23
fadro
https://www.dropbox.com/s/9si41oe52q90ksj/BoardStackup.pdf?dl=0
10:28
Bertl
I think you mean "beta board" where you write "power board"
10:29
Bertl
it would help to have a complete stackup and a list what goes where (i.e. what connections are between the boards)
10:30
fadro
what page for the "suspicious power board" ?
10:31
Bertl
page 1, the image of the "beta board" with a text starting with "The power board ..."
10:32
fadro
Yes you are right! beta board
10:34
fadro
And concerning the connexion of what goes where, the principe is simple : It keep the actual connectors. The only thing changed is the power connectors. Now all the power lines are fed through the bottom PCI style connectors.
10:35
fadro
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.
10:36
Bertl
well, yes and no
10:36
Bertl
you also mention a shift for the PicoZed, which would be about 1" at least
10:37
Bertl
and the entire stackup adds a lot of space on each side
10:37
Bertl
also introducing misalignment between the boards, which means they cannot be screwed together easily
10:37
Bertl
that's why I think a complete stackup would be a good thing
10:39
Bertl
something like this:
10:39
Bertl
https://wiki.apertus.org/index.php?title=File:PCB_Stack_Concept_V03_02.jpg
10:41
fadro
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
10:42
fadro
And even if there is sime misalignrùrnt between board, you can still screwing all board together. There is no problem to that
10:43
fadro
Furthermore, board have naturally strong mechanical links because of the construction ( the power backplane).
10:43
Bertl
that I agree with
10:43
Bertl
here are the points I dislike in the design:
10:44
Bertl
- modules become "complicated" and large, and probably lose the "plug" feature
10:44
Bertl
(i.e. they have to have the PCIe connector and connect from the side)
10:45
Bertl
- a new board and a lot of space (PCIe is quite high) is added at the bottom
10:45
Bertl
- with a proper power connector, we also add a lot of space to the side in this design
10:46
Bertl
- the power plane needs to be removed to change a module
10:46
Bertl
s/power plane/power backplane/
10:47
Bertl
and I do not see how the number of connectors for the high speed links is really reduced
10:47
fadro
OK, well let me answer:
10:50
fadro
1st, concerning the modules : I don't see xhy you loose any plug feature : that's the same concept you provide on your link, except that the introduction is on the side, not the back. And modules not necesseraly need to be large.
10:50
fadro
Then I propose PCI connector style, but of course we can easily find connector wich are not so high.
10:50
Bertl
your drawing shows a connector to the side (high speed) and to the bottom (power) for the modules
10:51
Bertl
which would not allow to plug in a module
10:52
fadro
Well what module are you talking about? The IO shield module or the user module??
10:52
Bertl
the one labeled "IO extension (actual IO shield)
10:54
fadro
OK, so the current design of the beta allows 2 IO shield extension. But on the proposal, you still hahe these 2 modules (in fact, only 1 is represented.That's the slight different green represented above the power connector
10:54
Bertl
okay, how should that work connection wise?
10:55
fadro
micro FMC style or any low profile connectors will fit
10:55
Bertl
to which side?
10:57
fadro
Yes, between the "IO dispacher board" (which holds the 2 user extension PCIe connectors) and the slight green board (the one above the power supply connector) on the global representation
10:58
fadro
so it is to the external side, to allow easy access for these IO shield extension
10:58
Bertl
to be plugged in, the modules can either have connectors at the back, or if plugged in from the top, then on the bottom
10:58
Bertl
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)
10:59
Bertl
note: per se I'm not against the power distribution board concept, but I don't think it solves all problems
10:59
Bertl
it provides good power distribution, there we completely agree
11:00
Bertl
it won't fit the actual power management system (because of the many connectors) or it will get rather large
11:00
Bertl
(remeber, our current power board is already crowded
11:00
Bertl
)
11:01
Bertl
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
11:02
Bertl
(i.e. away from the PicoZed)
11:02
fadro
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.
11:03
Bertl
yes, but I doubt that we will be able to use a fraction of the current space
11:04
Bertl
and with a reduce stackup, the total width of the power board would be 35mm or so?
11:05
Bertl
which is roughly the half of the current size, and it also has to hold all the connectors for each and every PCB (note that PCIe won't work either, because it wouldn't allow a 5mm stack height)
11:05
fsteinel_
changed nick to: fsteinel
11:06
Bertl
that and other minor issues is why I suggest to make a complete stackup drawing where you can see the dimensions and placement of each connection
11:07
Bertl
it is trickier than it looks
11:08
Bertl
you write PCI, but the same is true for PCI
11:09
fadro
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.
11:10
Bertl
still don't see how the modules should work (without disassembling everything) similar goes for the interface board
11:11
Bertl
and you still have to find those PCI style connectors which allow a tight packing
11:13
Bertl
the only real advantage I see here would be the improved power distribution, but that could also be achieved by using cables to route the power directly to the place where it is needed (with 1.5mm or even 1.0/1.2mm pitch connectors)
11:13
fadro
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
11:14
Bertl
no, why would you?
11:14
Bertl
the I/O shield is just plugged into the PCIe connector
11:14
Bertl
nothing else is required
11:15
fadro
So there is something unclear to me:
11:15
Bertl
if you look at the stackup drawing, the module is on the leftmost side
11:16
fadro
OK. but here we are speaking about the user extention IO module, not the shield module righ?
11:17
Bertl
we have two plugin modules (high speed I/O) and most likely (according to recent updates) two GPIO/microcrontroller shields
11:18
Bertl
where probably only one shield will be populated by default with a PIC32 module
11:18
Bertl
s/module/shield/ :)
11:19
Bertl
the "shields" are plug on like for the arduino (thus the name)
11:19
Bertl
they can be attached to the headers on the beta board
11:19
Bertl
(in the stackup, only one is drawn)
11:21
fadro
OK, so 2 users IO modules + 2 GPIO/µC shields. And i previously want to point out the GPO/µC shields. If you want to add 1 or change 1, with the current stackup, you have to disassemble most of the camera to achieve such operation.
11:25
fadro
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?
11:38
Bertl
I have no clue how you arrive at this conclusion
11:38
Bertl
the plug-in modules just need to be un-plugged and new ones plugged into the slot
11:38
Bertl
(no change, not even opening the case is required)
11:39
Bertl
for the shields, on the skeleton setup (for developers) you just remove the existing shield and plug on a different one
11:39
Bertl
probably not even screws need to be removed in a development setup
11:40
Bertl
for the PIC32 "now optional", yes and no, last week we had a longer discussion and we came to the conclusion that
11:41
Bertl
it would be a good idea to allow to customize the PIC32 shield easily, e.g. to replace it with a different microcontroller (atmel, TI) or even to leave it out completely (and maybe replace it with a debug module)
11:41
Bertl
in case the power management features are not needed/wanted
11:42
Bertl
note that the default setup for an early adopter will most likely feature a single shield with a PIC32MZ on it
11:42
fadro
OK, i just realize for the 2 shields board, they are connected on the front, so you plug it close to the IF bard...$
11:43
fadro
So you are rigth, nothing to disamsemble...Sorry i don't get it before!
11:44
Bertl
correct
11:45
fadro
From what i understand, things will be quite different between the early adopters version and the next revision of the boards...
11:45
fadro
So now i'll speak only for the next revision, not the early adopters one...
11:46
ItsMeLenny
left the channel
11:47
Bertl
careful, don't mix up AXIOM Beta with AXIOM Gamma
11:47
Bertl
if you are talking about the Gamma, then it's a completely different beast
11:47
fadro
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?
11:47
fadro
But i'm speaking about Beta camera
11:48
Bertl
power management for the beta is central and not an extension in the current design
11:48
Bertl
nevertheless it is (on purpose) on a single board, to allow for easy experimentation
11:48
Bertl
note that a power distribution board wouldn't be a problem per se
11:48
fadro
well but it is located on an extension board..(The IO shield). Why not to put it directly on the board?
11:49
Bertl
hmm?
11:49
Bertl
no, you got that wrong, the PIC is not the power management
11:49
Bertl
the PIC has direct access to the power management though
11:52
fadro
Yes, PIC as access to power management, and it will schedule power supplies, starting and stopping all the devices on the camera (FGPA, sensor, ...) isn't it?
11:52
Bertl
yes, it _can_ do those things
11:53
Bertl
the arm cores in the FPGA will be able to do the same
11:58
fadro
Yes but arm cores are not connected to all voltages monitors and power supply control. Only the pic is from what i understand?
11:59
fadro
So in this case PIC is not optionnal...?
11:59
Bertl
all the sensors will be on I2C busses, and the FPGA will also have access to those bus systems
12:00
Bertl
so the PIC is kind of optional, unless you want to power down the FPGA
12:01
Bertl
even the IMU(s) can in theory be re-routed to the FPGA if there is no managing microcontroller
12:01
Bertl
note that I originally had the PIC32 as a fixed component on the Beta board
12:01
fadro
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..
12:01
Bertl
but after a lengthy discussion with Francky, we concluded that we can make it more generic
12:02
Bertl
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
12:10
Andrej74
joined the channel
12:13
fadro
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.
12:13
fadro
And taking off some load on the arm cores depending on the PIC presence will complicate the SW maintainability
12:13
Bertl
it is a development kit and we want to allow for trying out a few things
12:14
Bertl
for example, folks will want to attach an LCD or similar sooner or later
12:14
Bertl
or add their own kind of special remote control
12:14
Bertl
all this (and much more) can be done via those shields
12:15
Bertl
it does not mean that we have to a) support the software side of all possible variations
12:15
Bertl
and b) it doesn't mean that we have to design our software without the PIC32 in place, i.e. we can just assume it is there
12:16
Bertl
if somebody (during development) decides to remove/replace it, s/he has to take care of the breakage
12:21
fadro
OK, so if the official release assumes that the PIC is there, why not to simply put it on the board? If people wants to tying out few things later, they will simply need to add and extension module or a IO shield...?
12:22
fadro
And if the purposes of PIC32 is collecting few data and low power management, a much smaller µC can be user...
12:22
Bertl
because they would need to rip out the PIC to do that properly and we still would need to have all the connections for the add-on shield
12:22
fadro
*used
12:22
Bertl
that is why we put it on a shield
12:22
Bertl
if we figure out that a way smaller µC is perfect for us, we simply change the shield and nothing else
12:23
Bertl
no redesign of the Beta board required
12:39
niemand
joined the channel
12:40
fadro
Well, i still quiet confused. The job for now is to provide enough IO and throuput to the IO shield. Don't really care of what is on the shield. So what is important is the IO shield interface itself, not what is on the io shield?
12:41
Bertl
I think you're again confusing the shields and the plugins
12:41
Bertl
I can understand this, because originally we called the "plugins" shields and had them mounted in a shield like fashion
12:43
fadro
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?
12:44
Bertl
but in any case, yes, the important part is to have enough I/O for both, shields and plugins easily
12:45
Bertl
yes, the shiields are at the front, beside the interface board
12:45
Bertl
the plugins are on the side, plugging into the beta board
12:45
Bertl
(at a right angle, via PCIe)
12:45
fadro
OK clear.
12:48
fadro
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.
12:49
Bertl
for the IMU (and other central sensors) we currently have a kind of solder on shield in the middle
12:49
Bertl
we might make it a full shield, but I doubt it
12:49
intracube
joined the channel
12:51
Bertl
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
12:52
fadro
ok for IMU, i agree with you. But sorry, i still don't understand the shield with the pic on it.
12:52
Bertl
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
12:53
Bertl
it is rather easy to do that, because we just need to drop the shield headers and put whatever is on the shield on the Beta board
12:54
fadro
So this mean that you xant
12:54
fadro
sorry.....
12:57
fadro
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!
12:57
Bertl
sounds good in theory, so tell me, what functionality do "we" plan for it?
13:04
fadro
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.
13:05
Bertl
that's what we plan to do
13:08
fadro
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.
13:09
Bertl
*sigh* simply because we do not know what the best solution is right now and we want to keep our options open, especially for testing on the early betas
13:11
fadro
OK, so you plan the shield with a PIC for the tests purposes with the early beta HW, right?
13:12
Bertl
yes, and there are three options how it progresses:
13:12
cbohnens
changed nick to: cbohnens|away
13:12
Bertl
a) we decide the PIC or any µC is a bad idea and we simply make it completely optional
13:13
Bertl
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
13:14
Bertl
c) we find the shield solution to be both, flexible as well as usable for our purpose, in which case we leave it as is
13:21
fadro
So when you say "flexible as well as usable for our purpose", you already konws the goal you are looking for, right?
13:22
Bertl
no, it will become visible during early beta testing
13:23
fadro
OK, so you plan to send some camera to "early customers" to have a feedback?
13:24
Bertl
we will do an early beta round, where we ask folks to participate and get an early version
13:24
Bertl
specifically software developers and similar
13:24
Bertl
but maybe also some interested hardware add-on developers
13:25
fadro
OK, and you'll wait to have enough feedback informations from the community to make such choices, right?
13:27
Bertl
it will be an iterative process, so each version incorporates the fixes/concepts/improvements gatherd from the previous versions
13:27
Bertl
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 :)
13:38
niemand
left the channel
13:54
fadro
That right, engineer ideas are not always related to users expectations...
13:55
fadro
And another question...(sorry!)
13:57
Bertl
go ahead, no need to apologize :)
13:58
fadro
For now the IF board is small because it is a simple pass through. But then, it will then considerably grow since an FPGA will be added to support sensor unified interface. And so, you will have far less space to put the shields boards on both side...
13:59
Bertl
this is a possibility, but we hope that we
13:59
Bertl
a) can get away with the currently planned space (might we wishful thinking :)
13:59
Bertl
b) that we can use the space now occupied by the PIC shield in case we don't :)
14:00
Bertl
if all fails, we probably need to extend to the other side, eliminating the second shield option there
14:02
fadro
hum, you mean to the other side of the beta board in case of failure?
14:02
Bertl
no, to the second shield side
14:03
Bertl
i.e. the side where the plugin modules are
14:03
troy_s
Shields schmields.
14:04
Pierric
joined the channel
14:04
troy_s
Bertl: A while back you mentioned the sensors are rated at variable voltage. What impact does this have on imaging from a capturing photons vantage?
14:05
Pierric
left the channel
14:06
PiFab
joined the channel
14:08
Bertl
troy_s: we really don't know yet, as we only had a single voltage on the sensor (for each rail)
14:08
troy_s
Bertl: Rather interesting.
14:08
Bertl
but there are indications that it might affect the nois created by the sensor
14:08
Bertl
*noise
14:08
troy_s
I guess it will be a trade off of sensitivity vs noise
14:08
Bertl
welcome PiFab!
14:09
Bertl
troy_s: it might be, it might as well be something you need to tune on a per sensor instance basis
14:09
troy_s
Indeed. Interesting to speculate how to voltage tune.
14:09
troy_s
(Figure out the underlying axes)
14:10
troy_s
Big huge knob on top. Low tech stainless steel with “Voltage Tuner” translated into three dozen languages.
14:10
Bertl
it might have some relation to overclocking CPUs
14:11
PiFab
left the channel
14:11
troy_s
Bertl: Darktable released a rather large post on highlight recovery
14:11
Bertl
i.e. higher performance possible with higher voltages, or lower power consumption with lower voltages at lower data rates
14:11
troy_s
If you are at all interested in that junk
14:12
troy_s
Sort of hints at the caged / trapped reconstruction which is partially applicable to Bayer sensor reconstruction in an oblique way
14:12
Bertl
yes, sure and I guess folks here might be interested as well, so go ahead, past an url
14:12
Bertl
*paste
14:12
troy_s
http://www.darktable.org/2015/03/color-reconstruction/
14:12
troy_s
I would say for the record when you are missing data
14:12
troy_s
You are missing data
14:13
troy_s
MatthiasF: Sort of a low tech version of what I was attempting to describe for the sensel interpolation to augment your signal reconstruction.
14:14
niemand
joined the channel
14:15
troy_s
Seriously problematic for post processing work.
14:27
MatthiasF
troy_s: Hello !
14:27
intracube
troy_s: I'm not completely convinced by the processing
14:28
intracube
I prefer the statue before processing
14:31
intracube
it's the lack of detail and flat shading on the repaired area
14:32
intracube
wasn't there a different method discussed on the magiclantern forums that could actually restore usable detail in the highlights?
14:33
MatthiasF
troy_s: I do not see the relation with our interpolation discussion though ;)
14:34
troy_s
intracube: It is all guessing, and in this case, I suspect possibly guessy guessing. :)
14:34
fadro
have to leave. see you soon. bye
14:35
intracube
I guess it's a difficult example as all 3 channels seem to clip at a similar point
14:35
troy_s
intracube: Statue is an awful example as well because it has as much to do with intensity as color; log curve to display referred zone etc.
14:35
intracube
you you can't exploit luma info in one of the unclipped channels
14:35
troy_s
MatthiasF: Remember guessing the value? That is part of the “trap” I was discussing; limiting the output colors to those that are known in gamut to a particular luminance plane.
14:35
se6astian|away
changed nick to: se6astian
14:36
troy_s
intracube: Luminance exists not as one, but across three.
14:36
troy_s
Luminance is the Y in XYZ.
14:36
intracube
troy_s: I mean in RGB space
14:36
troy_s
RGB distributes Y across (due to non orthogonal nature of XYZ) all three.
14:36
troy_s
So knowing two, you can get a good idea of the third.
14:37
troy_s
(In a purely display referred domain, if normalized to 1.0, you can nail it.)
14:37
troy_s
(Assuming of course you have an accurate model of the colorspace in question. In this case, the sensor's.)
14:39
fadro
left the channel
14:42
troy_s
intracube: TL; DR The sub optimal part of the statue is the rolloff to display referred white; the gold is not close enough to display referred white.
14:54
se6astian
good evening
14:54
intracube
troy_s: you mean in the processing they brought the highlights down too far?
14:55
troy_s
Yes.
14:56
troy_s
In the display referred domain, I would guess that your learned response to gold when reading an image is likely to slot that highlight in higher.
14:56
troy_s
As in, what is in that reflection? Sky. Sun. Etc.
14:56
troy_s
Your learned reading of the image is probably giving you a bit of cognitive dissonance there. Pure speculation and guessing, but that is where my guess is.
15:01
intracube
troy_s: there is some real data there in the arm highlights: http://pasteall.org/pic/show.php?id=85026
15:02
intracube
jpeg compression step doesn't help
15:04
troy_s
intracube: The moment you guess missing values like that the phrase “real data” goes out the window.
15:04
troy_s
:)
15:04
intracube
indeed, and the water to the left takes on a greenish tinge :P
15:04
intracube
but with some wrestling, that can be reduced
15:04
troy_s
intracube: I was _just_ discussing this via email with someone who is refining their HDR techniques
15:05
troy_s
They were using highlight recovery
15:05
troy_s
I basically said that HR is the bane of HDR work, so turn it off.
15:06
intracube
does highlight recovery have a specific meaning in software?
15:07
troy_s
Yes. Guess what the fsck a value is.
15:08
troy_s
Given R+G+B, where a single or dual channel of R|G|B is missing, guess the remaining.
15:08
troy_s
There are many ways.
15:09
troy_s
But all will likely (unless done by folks that _really_ get the gap between scene referred and display referred) will be wrong and futz all HDR attempts.
15:09
Bertl
it gets even trickier, as there is usually no way to know that it is missing :)
15:09
intracube
right - so all variants of the method in that link you posted
15:10
troy_s
Bertl: See above where I said “Not great” :)
15:10
troy_s
Bertl: Knowing the colorspace though, and assuming only one missing channel, it is plausible to glean the luminance position.
15:11
troy_s
intracube: dcraw has four. I am sure there are hundreds.
15:11
troy_s
intracube: Gets into signal processing if you want and subsampling. See MatthiasF and his field.
15:11
Bertl
given that you have a bad sensel, we can talk about "missing" but otherwise, how to define a "missing" value?
15:11
troy_s
Bertl: as part of a signal.
15:11
troy_s
Bertl: Rather easy to discuss “missing”
15:12
troy_s
Or rather subsampling along the signal.
15:12
Bertl
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
15:12
troy_s
Needless to say, even if looking at it as purely a constraints driven value of a set, we can estimate if we know the set, which in this case is a unique and finely grained colorspace.
15:13
Bertl
let's say the sensor is perfect, i.e. no bad pixels
15:13
troy_s
(I am not disagreeing with you. I loathe highlight reconstruction.)
15:13
Bertl
how to decide what pixels are e.g. overexposed
15:13
troy_s
(I believe it to be largely rubbish junk.)
15:14
troy_s
Well any that are clipped or into the junk data CMV12000 range. :)
15:14
Bertl
lucky if you have a CMV12k with a junk data range :)
15:15
troy_s
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.
15:15
troy_s
LOL
15:15
troy_s
2 bits?
15:15
troy_s
Of the 12?
15:15
troy_s
Or what was it?
15:15
Bertl
because if the sensor works perfectly fine, you can't tell a valid "255" from an overexposure
15:15
troy_s
Thats what I am saying
15:15
troy_s
255 is clip. Aka non data.
15:16
troy_s
Always.
15:16
Bertl
which will most likely yield a false positive for many sensel :)
15:16
Bertl
(just saying here, not arguing :)
15:16
troy_s
That is part of the problem... People are often assuming that the display referred mapping is a hard clip
15:16
troy_s
Which sort of ignores 100 years of grading.
15:16
troy_s
If you look at Blender for example
15:17
troy_s
The default display referred transform is a hard clip at 1.0
15:17
troy_s
With an sRGB curve on the data.
15:17
troy_s
Architectural rendering of course looks completely wrong
15:18
troy_s
As a result, instead of learning about the transform from scene referred to display referred, many artists instead do the _worst_ thing
15:18
troy_s
by adjusting their damn scene values
15:18
troy_s
Instead of realizing there is a transform in there.
15:19
troy_s
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
15:19
troy_s
and _then_ curving
15:19
troy_s
They mangle their scene data
15:19
troy_s
To cram it all down into the display referred range.
15:20
troy_s
Same goes for photography.
15:20
troy_s
Artists need a clear understanding of scene vs display.
15:20
troy_s
(Or output referred if you want a more generic term.)
15:24
Bertl
sounds like an article is coming up :)
15:33
Bertl
anyway, off for a nap ... bbl
15:33
Bertl
changed nick to: Bertl_zZ
15:46
troy_s
se6astian: A few changes
15:46
troy_s
se6astian: Minor. Hold tight.
15:55
troy_s
se6astian: There. I I think that hints at the cones in the eye better.
15:55
troy_s
Without getting all damn biological wall o text.
16:05
niemand
left the channel
16:08
Francky|away
left the channel
16:21
se6astian
great :)
17:47
Bertl_zZ
changed nick to: Bertl
17:47
Bertl
back now ...
18:10
aombk3
joined the channel
18:13
g3gg0
joined the channel
18:13
aombk2
left the channel
18:30
intracube
left the channel
18:30
intracube_
joined the channel
18:34
jucar
joined the channel
18:35
jucar
left the channel
18:37
niemand
joined the channel
18:39
jucar
joined the channel
18:41
slikdigit
joined the channel
18:41
slikdigit
left the channel
18:41
slikdigit
joined the channel
18:48
Francky|busy
joined the channel
18:48
Francky|busy
Re
18:48
Francky|busy
Bertl are you here?
18:50
Francky|busy
I saw some discutions about architecture and interface today
18:51
Francky|busy
I didn't have time to read back all but it seems that architecture is not very clear for all
18:51
Bertl
I am here/around, yes
18:52
Bertl
yeah, we need more documentation :)
18:52
Francky|busy
I think because you answer every time the same questions… :)
18:53
Francky|busy
And as the architecture is going more complex, it is going more hard to understand
18:53
Francky|busy
Except in your mind :)
18:57
Bertl
it isn't really bad that I have to answer those questions, because it helps me to verify the design
18:57
Bertl
but it would be good if somebody could pick up the expanations and put them together in written form (wiki, documentation, etc)
18:59
Francky|busy
Doesn't fadro make the official documentation of the project?
19:20
se6astian
fadro, not that I know of
19:21
se6astian
we will be shooting a new team talk issue tomorrow morning
19:27
Francky|busy
For my understanding : there is an official team and some contributors in apertus right?
19:42
se6astian
yes
19:42
se6astian
where the transition from contributor to team is a rather smooth one :)
19:43
Francky|busy
Ok i need to go
19:43
Francky|busy
Have a good night
19:44
Francky|busy
Bye
19:44
Francky|busy
left the channel
19:44
Bertl
nn
19:44
Bertl
and yes, fadro might be doing the documentation
19:44
Bertl
at least he voiced an interest to do so
19:45
se6astian
great!
19:50
intracube_
left the channel
19:59
intracube
joined the channel
20:42
slikdigit
left the channel
21:08
niemand
left the channel
21:10
jucar
left the channel
21:26
se6astian
time for bed
21:26
se6astian
good night
21:46
se6astian
changed nick to: se6astian|away
21:51
Jin^eLD
changed nick to: Jin|away
22:00
Bertl
off to bed now ... have a good one everyone!
22:00
Bertl
changed nick to: Bertl_zZ
22:09
intracube
changed nick to: intracube_afk
22:53
g3gg0
left the channel