#apertus IRC Channel Logs

ymc98: we are glad to have you ... please read up on the IRC logs from yesterday

off for now ... bbl

Good Morning!

hi RexOrCine

I see on https://www.apertus.org/GSoC-completed-results-report-smart-switching-regulator-article-oct-2017 that Apertus had a single GSoC slot in 2017 as it was the first time and I see now you have 6. Congratulations! How did you advertise to get so many talented students?

we got three slots last year

ok, I was looking at https://summerofcode.withgoogle.com/archive/2017/organizations/6354847569805312/

(at least we hope/think so :)

In https://developers.google.com/open-source/gsoc/help/slot-allocation they say "no matter how many slots are requested, new orgs are often only granted one or two slots in their first year to ease them into GSoC." Good for you you got three! :)

nope, just preparing the tasks and challenges

well, we have that anyway :)

In Pitivi we got three students last year and 3 this year, under the GNOME umbrella. We also require early involvment and it works good.

Is anybody from Zurich in your team?

not that I am aware of

hi

BAndiT1983: Can you explain me the color offsets related to the bayer pattern

?

ola TofuLynx; this? https://github.com/apertus-open-source-cinema/opencine/search?utf8=%E2%9C%93&q=coloroffsets

it's a bit tricky to explain

it just tells the image processor at which offset to get the pixel in which row and column

but, for example

and G1 also 1 and 1?

to me, it looks like some default initialization

this reveals the configuration for various Bayer patterns

ah, now i have it more or less

so it gets multiple pixels at once

but why is R initialized with the values 1 and 1, and G1 also initialized as 1 and 1? what do these numbers mean?

but maybe we can add the processing from your downscaler, e.g. which would get green pixels in both rows at once

it's easier to give offsets to the patterns, like blue at width + 2, in case of RGGB

I have to plan how I will implement the pattern system

or only after it's done, during the optimization phase?

RGGB - > red = 0; g1 = 1; g2 = width + 1; b = width + 2

so we could just do something like this: redchannel = data[red]

redChannel = data[redOffset + index]

and it's simpler, I think

very similar to downscaler

also one question

ask as much as you want

yes

Exactly

to the existing color array

but won't it be hard, as in, how do you work with offsets if it's always changing in size? You create an extra array?

that's not my problem

the debayer will modify the existing channel arrays, right?

how do you modify the channel arrays without "losing" the raw channel array?

but if the method is changed, then the image would be loaded again and processed from start

I think it's better to use a non destruitive method

otherwise we can store raw data and re-use it, not a big deal

I think we could modify the OCimage class

and add three new attributes related to raw info

we can reference the stuff from there, but the idea was to store just some integer value which points to the slot in the pool allocator

is there any advantage in using the pool allocator?

everything is stored more or less linearly and you allocate the slots, which are mostly equally sized for loaded frame/s

I see, so we would just need some pointer, as you said

Is it implemented?

planned it, but we can rely on some existing lib, posted a link before, have to find it again

Okk!

which progress?

ok, will look for it, but there are a lot of allocator libs on github, just have to find one which fits our requirements

there is a block allocator there, but it needs evaluation

Bertl_oO, is the expert there

it seems in fact straightforward and easy to use

yep

https://github.com/foonathan/memory/blob/master/LICENSE

compatible to any source or binary release if you ask me (non-expert in FOSS)

zlib is usually not a bad license

all FOSS/OH licenses are fine with apertus, as long as they do work with eachother (depends on project)

altering is not required yet, so it should be fine for now

even if, just marking is enough

dont see any risk with it. keep the LICENSE in the sources, and note if changes were made

as it also allows to specify commit number to checkout, we are relatively safe, if newer versions should crash or do funny stuff

see you

Good Night!