#apertus IRC Channel Logs

i.e. read the environment from sd and execute a specific 'axiomboot' or similar script/command?

danieel: Which display?

the one i like the most was in the first apple cinema display, lm300wq1

and the HP LP3065 is also fine

(Of course the HP outclasses everything in terms of control hence why it took up residence in every post house everywhere almost exclusively on the generic workstations)

we got also a U2412M .. but i do not like too much the LED backlight.. it is quite cold in color rendition

:)

And of course is relative to your adapted white point in your vision field.

the sad thing is that the 'default' is obviously flashed by Xilinx

hence if we want the default to work 'out of the box' that means that the empty ramdisk is probably the most 'stable'

so is our uboot executed or not?

on my board our uboot is executed with our configuration

on a default board the 'stock' xilinx is installed

i can't verify at this moment, but I can ask Sven, if i can check what happens on a completely vanilla device

well, if I remove the sd card, uboot should not work anymore, right?

so it is a very fundamental question, do we want to plugin an microSD card to any zync and have it booted

i.e. it just sits there without any console output

without sd card, no

as I said, boot configuration is (jumper wise) boot from sd

so I would presume the zynq lvl 0 bootloader tries to laod from there

you know you need to power cycle to detect jumper settings?

okay, so make sure sd boot is configured, then pull the card and cycle

also maybe "mark" your uboot with a recognizeable message/version number

you were right

it will only boot with a card hand has a red light

so problem solved?

I think you are right, that if we boot from SD

(and prune the unreadible mess)

(most importantly xadc and qspi, but I also suspect missing second port sd/i2c/spi)

i am still 'confused' why a stock configuration doesn't include them

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

comradekingu: received your buttons! thanks again! will forward them to se6astian for testing

off for now ... bbl

short server outage

gotta go

back now ...

off for a nap ... bbl

Greets all.

comradekingu: How you doing?

just had some freshwater fish cought ice-fishing

hey troy_s I am drafting a highlight recovery concept illustration currently, would you be so kind to review it once finished?

se6astian: It's pretty sludgey territory though in my opinion. I'm sure there are some more heuristic based algorithms (looking at nearby values for example that match the fingerprint of the missing channel) that might get a closer estimate.

Gotcha

back now ...

troy_s & Bertl please let me know if you have any feedback

great

ok :)

ah thanks

I'd make a _strong_ case that the whole "desaturation toward an achromatic" is largely learned from about 100 years of photographic imaging, where singlular hues of colors would burn through the layers of emulsion. That is, no matter what the color, everything converges toward white. RGB displays end up having this facet by default thanks to them being tri-colored display referred devices and you can only increase intensity so far on a single channel befor

se6astian: From _our_ vantage though, where scene referred idealized data is the key, the problem is more significant.

I think this becomes a bit of an issue for post production work.

Because RGB channels are arbitrary.

(In some uh... 'well behaved' colorspaces it does, sRGB for example, but that is the nature of the primaries chosen.)

personally I'm still not sure what I'm seeing there :)

(Agree, It took me a while to grasp the imaging.)

comradekingu: Explain?

you mean each channel has its own coefficient, instead of just R = B its R = Xb x B for recovery right?

se6astian: In terms of display referred white?

comradekingu: It's not quite that easy.

But there is a lot of computing involved to make sure the square is where its supposed to be

comradekingu: If you think of a colorspace as being weights in luminance, they sum to a unity in the display referred domain. So sRGB for example, has primaries of 0.2126729 0.7151522 0.0721750 luminance at D65 "neutral"

so it is something introduced by the image pipeline

Bertl: yes, currently in Alpha we simply do not white balance

the output is always raw

so why would we 'throw away' sensor data?

well, if we output the 'raw' then we don't either and nothing needs to be done. period.

true, then it should happen in post processing

And it is a challenge for certain in post.

Because that data isn't data.

we don't output raw yet (on the alpha)

only if you capture a still image

no white balance is white balance as well :)

true

For the onboard viewer.

Otherwise there is going to be some nasty castings.

but I suspect that post processing software does not recover highlights when it re-balances the whites but just crops off the data

se6astian: then the post processing software should be adapted

the problem is this, when _we_ do this on the raw data, we are actually making it worse

Bertl: That would allow colors to converge like film, and eliminate casts. So when green is say, 95%, the 3D LUT yanks up the R and the B channel to converge more gracefully at unity for the display referred transform.

Agree.

not something I would really want :)

And in post, any transform should be in the scene referred domain... for example, if R is 0.8, B is 0.7, and G is pinned, then the estimate should come from nearby statistical Greens.

Yep.

And totally fubar any and all colorspace transforms off the data.

each pixel is 1080p contains R, B and G so we can fill a 2x2 bayer block by just taking the channel values

I think RAW development software does account for the highlight recovery process

yes, you can do it, but it will be just wrong :)

its an experiment

but wont it look unnatural when you try to represent it in a limited colourspace?

Well the larger issue is that there _is no data there_

And that causes all sorts of hell in trying to leverage the data in say, compositing.

And as such, the chance of a guess being _way_ off is quite high.

if you do the sort of blind and ignorant "desaturate and reduce" now you are screwing your scene referred values for compositing.

I personally believe there is a vast amount of more research to be done on optimizing the log curves for capture.

is there a way to couple many axioms together to only use the middle part of the lens

so where you would otherwise be on the curved side bit, you instead shoot that on another camera

but yes, you can synchronize several AXIOMs

comradekingu: It won't be.

(although in most instances it is quite uniform in my experience.)

yes, but that isnt as cool

if you can also do 3d and increase the resoution a bit it beats the bigger lens

Bertl: Mega car chase with a robot car that smashes another real-world car and is dissipated with a laser. Where that real-world car was and gets dissipated needs to have background plates so that it can be removed.

Bertl: Or Mega car comes down and lands and drives along a road. That road needs to be shot at large density so that it can be mapped to 3D and used to generate camera motion and 3D etc.

i imagine that gets easier to do if you can have it preconfigured to shoot like that, where the cameras communicate and notify you if its off