#apertus IRC Channel Logs

Bertl: Something like .AXI

Bertl: Well I'm thinking ahead slightly. I'm about to write a stub for OIIO.

relying on an extension is always a bad thing, but that's unrelated here I guess

Make sense?

i.e. it isn't a file format per se

not knowing .axi, I can't tell how much work a similar converter would be

Bertl: If you are writing the firmware, at least put a magic code or something at the head pehaps?

well, that's what I mean, a file format should have some mime magic

but .raw16 is not intended as a format

i.e. I don't want to create a new format here :)

You already are dumping data.

it is raw data

they still encapsulate it in a meaninful wrapper

The extension.

well, .raw16 has the .raw16 extension, no?

It's kind of a crap extension, yes?

hmm, why?

And it isn't exactly a useful descriptor.

Yes.

so where is my AXIOM.txt from?

Oh god.

.raw16 doesn't mean anything

it's the data from a bayer sensor on a prototype axiom camera

but as one of the fellows that might try to write some code for decoding the file, how about an extension and a magic number as a test?

yes, but obviously there is no generic format for that which doesn't involve a million tags and complicated structures like dng

I'm not telling you that.

we will do that once we know that we 'need' or 'want' a specific axiom format

So a magic first word header is too much?

good news! I patched the bayer2RGB code to work on the .raw16 file

yes, because it breaks the ability to access the data easily

it successfully ran with VNG

I have to rely on raw16 as the extension with no helper check

e.g. now I can do display -size 4096x3072 -depth 16 gray:example.raw16

(without implementing anything)

Urgggghhhhhhhhhh...adlfkja;lfkjasd;flkasjf;lasjf;lasfkjas;dlfkjasd;lfkj

Moving on.

Enjoy staring at your black and white bayer pattern

gcolburn: VNG?

Bertl: The bayer2rgb code was not calling the 16 bit converter when you do -b 16

so I just put the function call in LOL

and presto, the tiff comes out correct

maybe send the changes upstream and check the tool into the axiom repository?

Is it at GitHub?

I searched the code. it seems to set a flag and not use it

I get the same image with or without adding -swap

great!

troy_s_: isn't there a format in OIIO which already supports raw data in bayer matrix?

if not, maybe a generic 'raw' (not in the camera specific raw sense) plugin would be appropriate

Bertl: No

Larry has been developing code for too long to make such open ended bits of rubbish.

It makes a number of assumptions and design context decisions... only associated alpha, no random different bit depth, only a very limited subset, etc.

DNG is a great target for the raw data to be converted to for folks who want to dicker with the debayering etc. I'm only going to implement a very focused bayer -> VNG -> RGB (of a given colorspace) implementation if I can get it working.

so why not do a plugin as I suggested then? should do the trick and doesn't need to support any sizes/bitdepths we do not encounter

I'm doing the Axiom plugin. Or at least I intend to. Trying to get my build environment working as I need.

DNG is again, a no argument discussion when it comes to storing the raw data into a single frame if needed. My gut says that we should likely dump the speediest raw format we can to disk though. Rather like ArriRaw.

what I mean is, why does it need to be an 'axiom' data format, why can't it be a raw, 16 (soon we will switch to 12 :) bit linear (gray) image with bayer pattern?

It doesn't need to be a data format.

like a checksum or so?

we can easily append a crc32 at the end, if that helps

I see your need for a basic "display foo" but I'm merely trying to get a plugin in place that makes our ability to go to say, EXR or DPX or JPG a click away.

(Which again, I think is a really sub-optimal focus at this point given our design constraints.)

(What I _really_ don't want to see is DNGs getting posted and then countless idiocy spiralling out of control when someone starts talking about color being off only to discover that their FooBarDNG reader was malforming or doing something odd.)

Bertl: We write one plugin stub and we get TIFF, JPG, DPX, EXR, PNG, TGA, etc. all for free.

I'd focus on two points this early on for testing purposes.

I agree, I'm all with you on that

so an crc32 at the end would help you? we can do that easily and older raws can be easily 'upgraded'

I don't know. The readers all start at the beginning. I suppose I could do a quick calc. I'm only thinking that for our purposes some sort of really trivial check would be at least a good step forward for reading files and validating that they are in fact decent.

(as in if someone doesn't know what an EXR or DPX is, they are less likely to download the image and gripe about incorrect image results which is arguably happening already.)

So a simple stub plugin for OIIO gets us well on our way without worrying about all sorts of libraries and cruft.

The first line in OIIO is obviously extension

Pretty simple and lean.

i.e. all plugins registering for an extension will get a chance to process the data?

Bertl: Just like a jpeg

Bertl: As we can always craft the stub to be whatever we want.

But your CRC idea isn't an awful one.

at the moment, we generate the 4k images

another quick question Bertl, Gabe is hitting a wall with some of the calibration / profiling issues

So I was hoping that you might be able to get that noise reduction in place sooner rather than later?

See my concern?

We really should get that profile locked in as if the sensor has a ridiculously small gamut... well you won't be winning any supporters with that sensor.

it will fix all the LVDS issues, but the tools are stubborn

Bertl: Right now I think we are zoning in on getting the image quality up to snuff and all that it entails.

Bertl: Especially in the "Is this sensor suitable" zone.

yeah, but I don't see a point in using images where we cannot guarantee that we have the actual sensor daa

I have a few days before I fly off to Spain that I'll try and get the damn OIIO stub working, and then from then if gcolburn gets better images, we can use a better matrix and evaluate using something like Blender or any other OCIO enabled app.

(For the nerds that want to see that)

Bertl: What do you mean?

as you can see in some images, there is some corruption going on

that's why I redesigned it and already verified that it is working reliably now

I get it.

The idea that we get the image 'as best as possible' is probably high on needs at the moment.

So that we can do secondary evaluations.

Are you stuck with them forever?

if we switch to Altera, we get a different set of proprietary tools with similar issues :)

Yes. Different set of problems I'm sure.

(at least according to their answers on the forums :)

thanks for all your hard work on it Bertl. someday I hope to understand the FPGA programming side in depth :)

it is fascinating to some extend, but it also involves a lot of waiting and working around 'broken' tools

I understand that the stuff is proprietary

(way out of my depth so it is all crack dream)

so, while gcc gives you something like missing semicolon in line 17 column 23

Awesome

Grab goat and sacrifice compiling. Awesome.

so you label a variable foo, and it ends up being called xilinx_bar_recomp_some__i_7 (no joke)

off for a nap .. bbl

morning everyone!

hello!

good good

okay?

so its stacking combined with slide in modules

not sure if its THE best of both worlds but at least it keeps modularity to change the size of the camera high but does not spend a fortune on FMC(or similar) connectors

excellent!

probably

ok

sure :)

hurray!