#apertus IRC Channel Logs

morning everyone!

off for a bit

BAndiT1983, Bertl are you available?

MK: check out the existing VHDL code base and try to follow that

writing a style guide would be appreciated (e.g. for the wiki)

Bertl, writing a style guide is a pretty good idea once i deliver my proposal

anyway, try to get close to existing VHDL (from AXIOM Beta) and if there are questions, just ask ...

Bertl, Thank you very much that will be very helpful

you just missed BAndiT1983, he's 'the man for OC'

giacomoalbe: no, check the irc logs for the second question, and probably yes

supragya: It's not a software related question, well kindof. Since this is my last year as a student I'd like to applicate for the GSOC with the Apertus project. I'd like to work on OpenCine.

My idea would be to make the tasks tagged in the Phabricator as GSOC_2018 and also add initial editing capabilites to the sw.

I saw on Phabricator that OC has a "column" (don't know how to call them) with a proposal to add Lumiera as a backend, so I think that in the roadmap adding NLE capabilites is planned as a feature.

no... it's better to do it, get reviewed etc

the GSoC application deadline is the 27th of March

*advisable

you have to add the code to maybe github etc

then link it in proposal

About the weekly schedule, how detailed should the "delieverables" and "organizational stuff" be? I mean, may I just write "week1: Understanding Debayering techniques" week2: "First Prototype of Algorythm working" week3: "Integration in OpenCine" week4: "Research on best NLE backend" ecc or I have to be more precise on timing, goals and intended outcomes?

e.g. week2: working on stuff <-- bad

(of course, requires context)

I hope to manage to do that!

I am unsure of NLE capabilities in OC... what is the task?

Right now there's not a task, it was simply a proposal to add NLE capabilities to OC. The idea was to reach that level of pro "thing" in order to be used as a professional tool rather that a simple MovieMaker clone. My idea would be to ease the integration with other softwares like Blender or Natron or any other specific software in the field of VFX/Professional Media production.

i would suggest you take a look at OC first, build it and try it, then propose. :)

ok :)

I am not sure about NLE... but as far as I know OC is very basic in its functionality right now

you can propose whatever you may like, its upto you :)

But for GSoC, i guess that would not be a factor, again as Bertl suggests, BAndiT1983 would be your guy :)

I am just a fellow GSoC applicant like you :)

But after that I think that a software like that (capable of becoming the "best" companion of any Apertus camera) might also add some integration with other professional software (FOSS and commercial) and also a professional timeline with industry standard quality will only benefit the project.

The initial task of adding debayering decode methods to OC.

no... I have been here for a month now... know a little bit of OC

Ok, I think we need to wait for BAndiT1983 to shed some light into this darkness ahah!

supragya: are you proposing for the same task?

but one guy is

Yes yes, I know! So let's wait for some feedback from BAndiT1983! Thanks to all for the support, help and love, I need to start working on something :)

was it a selected GSoC proposal last year?

Hey Bertl, there?

I have updated some things in my propsal that we discussed, it'll be good if you can tell me if I did right.

did you already submit it as draft?

The proposal? No, I want it to be reviewed first

BertL three sensors are mentioned on website for axiom beta sensors, in task t728(emulating sensor) it is not clearly specified which sensor to emulate

yeah, the main focus is on CMV12k for now

seems fair 90% voted for it

most likely because the rows in the raw image are 'swapped' i.e. not how the converter expects them

another issue is when somebody forgots the CM1 being xyz related and puts in a rgb2rgb matrice

ooook thanks....and I have some question about the 12 to 16 bit raw conversion: if all files are all little endian a 16 bit raw file shoul look in every touple like x0 yz (hex) why instead some of them are x1 yz?

looking at the cmv_snap3.c code (v1.10) I'm not sure how that could happen though

Thanks Bertl. Another issue I'm having is trying to understand how the conversion to 16 to 12 bit is done:

if for example i have A0 BB C0 DD E0 FF in 16 bit little endian i would first convert it in big endian BB A0 DD C0 FF E0 then remove the LSB and combine. ->BB A DD C FF E-> BB AD DC FF E... and then in little endian AD BB FF DC ...

the conversion happens from 12bit to 16bit as the FPGA stores packed 12bit in memory

can you make me an example?

and this is written as two bytes, 0x30 and 0x12

you are wrong, the image pipeline gives packed 12bit output

so if my 12bit files looks like 12 34 56 78 9A to convert it in 16 bit i nedd first to convert it in Big Endian 34 12 78 56..... and then add a 4 bit 0 padding : 34 10 27 80...?

(is this a question?)

it then write out the bytes high to low

12 34 56 -> 123456

123 and 456

cmv_snap3.c writes the msbs first

(I'm apologize for the questions but i found nothing on internet)

this is then written out as 0xAA 0xAB and 0xBB

and then it's saved in little endian? so 0xAB 0xAA etc..?

ok but why is specified that the raw file is little endian?

not sure I've seen the 'specification' ...

so maybe the conversion in 16 bit is done with little endian

as I said, 0x123 (12bit) is written as 0x12 and 0x30

Bertl: that is big endian ( 0x12,0x30 -> 0x1230 )

danieel: right

Bertl: i thought the endiannes is correlated with how you save files not how you read them

you can read them how you like

in which case the 'interpretation' depends on the architecture

will give 0x12345678 on a big endian system and 0x78563412 on a little endian system

no, not how it is written, but it might affect how the data is retrieved from memory

ok thanks for the help man ;)

ok but why my first line of the raw12 is 08 00 77 08 and the converted (raw16) is 00 08 70 07 50 and not 08 00 07 70 ...?

00 08 -> 0800, 70 07 -> 0770, etc

and the original 12 bit values are 080 077 ...

to make it easier for the next people coming to the project asking themselves the same questions as you did

se6astian where?

simon: https://wiki.apertus.org/index.php/RAW12

good night

nn