#apertus IRC Channel Logs

rexbron: the debayering script ?

FergusL: How long has the debayering script taken?

actually I'm not entirely particular on that

that can act like a camera and output quality images to a PC

it will be limited to full HD, because there is no interface with more bandwidth available on the zedboard

(but you should know that, IIRC, you have one, no?)

Do you think DNG at 24fps is realistic by april?

ok

then the hardware development and testing

hmm

wow, that is quite some time :)

Yes but it's not python's fault that it is that slow

Totally wasting time

I assumed the dng converter was doing the job well

Yes, I assumed that was better for you lot

Yes

Though I realise, dcraw needs a profile for the camera which we don't habd

working on that would probably be a good idea as well :)

which you can get in at least three different ways by now

2) with a tool called bayer2rgb

FergusL: why is it doing the same calculation 4 times, why not avoid that by altering the algorithm?

dmj_nova: because I was just a bit stupid and overlooked how it could make my script that slower! It's actually unusable indeed atm so yes I need to rewrite some part of it

I need a maths tool called a graph

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

morning everyone!

cool

fantastic!

see you

wb aPinky!

ah hello pinky, you must be our new robotic friend to log the channel

back now ...

okay, note that you need to adjust the scripts to handle DVI out

yes

the base HDMI test that ships with the zed board and displays a default image worked fine

in

I disagree, for example the X-Trans pattern is 522

nah, just google power :)

Bertl: Odd... so it samples from a block of five pixels?

Slightly worse scaled chroma. I cannot imagine that nightmare when it gets into macroblock compression.

actually wikipedia says it is 6x6

Bertl: I intend to actually try and hammer on the image when I get home, but sadly am also on six day weeks currently.

I wish DNG were in OIIO. That factoid makes it hard for me to be behind DNG currently. It makes integration a nightmare.

regarding DNG, it is one option atm, I'm not sure that deep color tiff isn't a better one for test images

DNG certainly seems almost appropriate for the "one format to rule them all"

TIFF not so much

And DNG certainly seems more appropriate for dumping Bayers.

for fast debayering on the CMV12000 images I've just been running dcraw on the DNG

sort of

gcolburn: You can easily scale and crop that IT8 if need be. Just be sure that whatever app isn't mangling - and that isn't easy.

I worry that the image is slightly underexposed

exposure is important on IT8 work as the saturations of the wider colors is inherently part of luminance - which in simple terms means that the color may not be reached without sufficiently intensity.

Bertl: OpenEXR (intra pipeline) and DPX (between or to print)

yeah, not talking bayer pattern images, more talking debayered here

if I don't have much luck with that open source package for the calibration I was thinking of implementing this algorithm here: http://www.cs.sfu.ca/~funt/AIC2012_Funt+Bastani_IntensityIndependentColourCalibrationAsPublished.pdf

gcolburn: Wiser is to simply get to Argyll working, which is assured and vastly more reliable.

maybe troy_s can help with the error on argyll?

yeah, no problem with dpx there, as it is supported

gcolburn: Oh yes.

gcolburn: I use it to generate 3D LUTs for display profile transforms

Bertl: It is in the best interest to limit the file choice. Make it as focused and streamlined as possible. As much as I am pro DPX, it is a layer of abstraction upon a lower level format like DNG.

(and the BMC folks would also likely find a supporter or two)

And that pretty much wraps up every postproduction pipeline out there.

As both DNxHD and ProRes are encumbered IIRC. (The latter certainly, the former almost certainly)

IE: A standalone GUI / CLI application that allows for a DNG to ProRes / DNxHD transfer with a one-light baked in optionally.

gcolburn: What issue are you having exactly sir?

Bertl: gcolburn will need the data files.

change .png to .raw16 for the bayer images

actually .raw16.xz (i.e. compressed)

Rxxxxxx.txt

https://github.com/hughsie/shared-color-targets/tree/master/targets/wolf_faust/reflective

https://github.com/hughsie/shared-color-targets/blob/master/targets/wolf_faust/reflective/R100604.it8

Bertl: Shipped per IT8

(rather like the profile for a specific monitor)

as the number matches the one on the IT8 chart?

and are worthless as the knowledge people that suggest they are useful.

I believe the Rxxxxxx.txt file is specific to the IT8.

anyway, I think the R100604.it8 is at least a close approximation, as it seems to originate from Wolf Faust and has the same numer as on the IT8 chart I have here :)

or if you mistrust the person on github, maybe this here is the better source: http://www.targets.coloraid.de/

for my testing thus far

Bertl: They ship per chart sadly

I'm not sure they exist per chart though

"The individually measured target reference files and OEM target files are only available on request by email "

the question is, how to identify the specific chart?

how old is the chart?

the read me in the download stated after about two years its best to get a new chart

but maybe 2010:06 means something completely different

Bertl: “IT 8.7 compatible reference file containing the color measurements for the target.

yeah, I just wonder how you get those files when you only have the chart, because the chart has no unique identifier besides the charge number and the date

(per print batch)

yes, I had to fight to keep it low, the chart is very reflective

just look at the bootom, the gray there is uniform on the chart

okay. how much trouble would it be to get another shot with the defect columns off of the patches? the relative error in the profile that was generated is too high. if we crop the image I think it will have a hard time picking out the patches since they won't be the right size

Here is the link for posterity

http://trumpetpower.com/photos/Exposure#Normalizing_exposure

troy_s: I'm still confused as to why you have a hate on for tiff

What is beyond my knowledge for the implimentation is there needs to be a feedback mechanism to pass settings to the underlying plug in (white balance, exposure comp etc).

rexbron: EXR is the single format really required (TRC / color as an aside / parallel need of course)

EXR is more robust in all facets.

DPX has a TRC metadata tag

rexbron: Storage is free. It isn't storage either... it is precision

(both in full, half, and stereo)

TIFF gains nothing over half!

I don't disagree

uhh, it's moot when compared to DPX really

My point isn't a TIFF hate on, just that it is only acceptable when the others are unavailable for whatever reason

rexbron: Transfer. Period.

Largely due to the TRC issue

(1.6 Cineon seems the bog standard)

Total sense for mattes

But still images less so.

my qualms with DPX have to do with implimentation issues and color assumtions, that we have both come across, in the lower level libraries.

troy_s: and the context has changed!

rexbron: Agree on the shooting front, _NOT_ on the post house front.

rexbron: And to be fair to DPX, it too is robust as hell. It isn't just a legacy “gosh we all hate xxx format” - it fills its role well. (Albeit a little too powerful and doesall)

(as in it almost does too much)

has

Format crusades...

Again, I am not against tiff.

well tested implimentations

Fair.

Am I a user or a library in this context?

Any app.

So perhaps you misread my opinion of TIFF. I would rec no other format to be honest. Given still images of a photographic nature aimed t post production however, that context leans me to DPX for the still component. Can TIFF work?

I don't know where in the TIFF spec is states a TRC

I'd be curious to know

rexbron: Grr... wait.

rexbron: Page 84

TransferFunction

Pixel components can be gamma-compensated, companded, non-uniformly quantized, or coded in some other way. The TransferFunction maps the pixel components from a non-linear BitsPerSample (e.g. 8-bit) form into a 16-bit linear form without a perceptible loss of accuracy.

http://pastebin.com/LfTAPM9b

good night!

FWIW, here a 'fixed' version of the chart, no 'debayering' per se, just an overlay of the colors

(the sensor artefacts have been removed)