#apertus IRC Channel Logs

http://vserver.13thfloor.at/Stuff/AXIOM/BETA/improved_register_settings.png

note that the png is the raw image 'debayered' with the simple imagemagick debayer (i.e. combine 4 sensel into one RGB pixel)

troy_s: let me know what you thing of the all new an improved "look" of the AXIOM Beta :)

just for the record, no FPN correction or other alteration has been applied, this is the raw sensor data

Bertl: The smartest approximation going is to attempt and distribute equal bits per stop.

Bertl: And I don't understand what you mean by "reduce green channel by 16%"

yes, i.e. just reducing the green by 16% makes it look nice on the HDMI feed, nothing more

Bertl: Can't wait to look into the images.

it is the raw data for the (same named) png

Can't see what it is of. ;)

Also, to everyone in here, read this great article by Thomas...

ah, damn, I'll re-upload it

so, png should be fine now, sorry for the confusion

Wow... Reminds me of Viper footage dumped raw to sRGB primaries!

irieger: http://www.curtpalme.com/ChromaPure_JETI.shtm

Bertl: That is terrific.

great!

troy_s: Our color guy here prefers the Photo Research things over the JETI spectros.

hi Gaudis!

I would like through this chat to share knowledge about the realization of these extraordinadias cameras and help in what I can

also worked in the audiovisual area

in my country it is very difficult to obtain high-definition cameras , have many limitations. And as an advocate of free software and hardware you have proposed this project to various partners and we learn from their experience in the development of these cameras here ... to open a chapter of the project apertus here in Venezuela

We would like to contribute what they can or even buy the most basic camera to go slowly learning

so far is that dared to write , and for me it is an honor to talk to you

back now

sounds wonderful

For acquiring a camera please join the preorder notification list here: https://www.apertus.org/axiom-beta

"Register for preorder"

once you have a voucher you get the axiom beta at-cost

with feedback, ideas or software development contributions

then it will be more stable and solid

no matter when you decide to get your camera unit

We started collecting Phase 1 payments last week

Wait for a minute that I am translating , I do not speak English

that they are under development right now ?

we are now shifting focus on software development

if I buy a camera axiom beta , you also give developing manuals ? or only the camera ?

what do you mean with "developing manuals"?

Sure, I'm writing and planning the project , and I need as much information for people who can support me

great

our proposal is to form a multidisciplinary team to study the development stages of the camera, and from there into a school that will serve for the development of new cameras .

I'm using this translator is very bad

we know that this project is not possible without help , so we wanted to have your support ... and also to extend our help you count on us

woow excelent

irieger: Haven't heard of them. Looking.

irieger: Rather sure that to test sensors, light boxes, etc. at some point a spectro will be required. Not sure how feasible it is to keep renting them etc. Plausible for a little while.

How be things folks?

currently we produce RGB 444 output for HDMI

we will be able to change that in the (near) future, but that is what works right now

yes, the shogun does the conversion and compression

right

we also want to avoid sudden color changes, as they will result in wrong pixels

correct

sudden color changes = areas with high image frequencies, right?

the problem with that is that 7:0 will produce thos sudden changes

which in turn will mostly affect the lower bits, which is what we want to avoid

yeah, but that might not be so problematic if we have redundancy

I'm thinking to optimize the bit order numerically, on a test image

I thought about that as well, and while we can do that, it has a number of bad side effects (speculation i.e. untested)

consider a 12bit gradient from left to right

everything is extremely smooth

and use it for 8bit RGB

and 15 problematic points where 255 suddenly changes back to 0

*almost

and that is for smooth images which we "assume" as typical input

on the other hand, while the codec changes some bits, it is designed to do it in a way not directly visible to the human eye

which means that if we create smooth pixel sequences, the codec is forced to be more precise than on huge changes

where we need to test if the shogun does sharpening at all first

yes, I already started to write a simulation in octave

the mimg tool can also generate artificial test patterns (feel free to add your own there)

https://wiki.apertus.org/index.php/AXIOM_Beta_TestsTODO

there is a script called rectest.sh, which will cycle through the test images with the 8 encodings

which can be easily adjusted for new images/patterns and/or encodings

if you want to use a live image for tests, there is a script as well, you just have to freeze the live view (fil_reg 15 0)

for the TestsTODO, I would suggest to make a number of test chart images (preferably gray sequence) with different ND filters so that we have overlaping ranges

you mean a printed testchart not an mimg right?

(i.e. different pipeline :)

but what mimg should we use for the HDMI rectest.sh recording?

(with various test patterns)

right

Watch your illuminants. ;)

so, I'm not sure what else to ask for right now

alexML: you should definitely get new sample images since we fixed the sensor registers, thanks to irieger

(see the one snap shot I uploaded last night)

http://vserver.13thfloor.at/Stuff/AXIOM/BETA/improved_register_settings.raw12.xz

http://vserver.13thfloor.at/Stuff/AXIOM/BETA/improved_register_settings.png (IM simple debayered)

Who is the fellow in the thread commenting on color noise?

Bertl: What was the process for your simple debayer off of the raw 12?

https://wiki.apertus.org/index.php?title=AXIOM_Alpha_Software#Simple_debayer_with_ImageMagick:

the flipped line was used

Bertl: Tripping an unexpected end of file. Any reason?

Bertl: Any idea?

Bertl: Hit me back when you have a moment. Love to get a quickie debayer.

(the line originally was for raw16 data)

Bertl: Would be super lovely if you would dump tifs at the very least. Not to go into the PNG discussion again. (All of the colour profiling tools can't read PNG)

(for testing)

(and you will get tiffs :)

Bertl: I love you.

alexML, se6astian: i.e., just let me know what bits go where in the two consecutive frames

okay, no problem

Bertl: You want the XYZ matrix?

sure

- !<MatrixTransform> {matrix: [0.775918, 0.905383, -0.288160, 0, 0.035324, 1.738325, -0.511805, 0, -0.177910, -0.546866, 3.364549, 0, 0, 0, 0, 1]}

Those are the OCIO transform if anyone wants to use a viewer.

- !<ColorSpace>

family: Spaces

bitdepth: 32f

AdobeRGB compatible space as outlined in the Adobe RGB 1998 specification

allocation: uniform

to_reference: !<GroupTransform>

- !<MatrixTransform> {matrix: [0.775918, 0.905383, -0.288160, 0, 0.035324, 1.738325, -0.511805, 0, -0.177910, -0.546866, 3.364549, 0, 0, 0, 0, 1]}

That of course assumes a strictly D65 sRGB scene linear reference space

http://www.pasteall.org/62621

Bertl: Easy to view in Blender if you add that stanza.

I reused my existing Adobe RGB stanza, so the description is obviously wrong.

I probably should have made the synthetic white D65 but alas.

That's with an appended syntehtic D65 on it.

(So that's basically an absolute colorimetric representation in D65, meaning it will look "Warmish" on a D65 display.

Here's three stanzas, with the last not having any synthetic white appended http://www.pasteall.org/62623

(That is with a synthetic D65 appended. Probably not the wisest choice, but alas.)

Bertl: Image looks like a great starting point though. Much, much, much better than the previous Alpha efforts it seems.

yes, we are very happy with the progress

Bertl: Pretty sure the results would be a very solid entry.

se6astian: ^^ have a peek

yeah, of course

Bertl: Hard to know how that matrix would hold up as there isn't a huge bit of variation in the subject matter to really test it's limits.

Bertl: Is it just me or is there odd flaring going on there?

so, conditions are primitve, we need images under well defined conditions to evaluate that

That is, I'd be able to create a proper OCIO configuration if we can get a sense of the LUT for values to radiometric values

Right now, it's display referred.

(currently)

Bertl: So that is 'just roughly linear'

irieger: Would lvoe it.

that's what I planned for tomorrow ;-)

troy_s: if it helps, I can give you the offset that gives consistent color in the gray patches

(so, subtract 18 from all values)

alexML: You can't just offset

alexML: Make sense?

troy_s: raw data usually has some constant offset on it (on Canons it's 2048)

alexML: Sure, but that offset is related to the noise floor.

yes, and I just tried to guess that offset for this particular file

I'm pretty sure that LMS will properly calculate the XYZ coords regardless.

I'd need to triple check that though.

alexML: But you don't know what the colour space is

alexML: You are inferring that R=G=B=Achromatic, which is absolutely false in this instance.

Either.

What you are looking at is basically a "hey here's some data" dumped randomly to a (typically) sRGB screen

Nothing.

The only reference point is that colour chart, and that is wound up with the XYZ positions for the various swatches (which in the case of a low quality chart such as a passport, you don't even get a spectro measured one)

You can't assume that about the ratios

The _only_ time that applies is if you are in a colour space that has been rationalized with an achromatic axis where R=G=B=achromatic

Given that sensor, there's exactly zero chance that the ratios do that.