#apertus IRC Channel Logs

Goood morning everyone!

morning Tanos!

https://www.apertus.org/axiom-team-talk-volume-12.3-article-march-2017 is out

with the best ever article teaser image

I think he will

okkay . Thanks.

yeah . can you tell me which is the class which I should look to get the path to the image in OCCore.

when I grepped "ThumbnailProvider" in OCBackup, it shows that QMLThumbProvider is used as class where as in OCCore , it shows ThumbnailProvider as the class.

OCcore and also OCui are shared libraries, .so under Linux and .dll under Windows

you should take a look at ProcessingTest which uses both and is a playground to test features, also image loading

as the proof of concept was done quickly, so i haven't moved the code to thumbnail provider class and put it directly into QML thumbnail provider, cleanup and restructuring is still on the list

i told you before that ProcessingTest is the right module to start, it already loads files, but the path has to be adjusted there, if i remember correctly in ProcessingTest.cpp

Yeah. It does load files.

take a look at ProcessingPresenter.cpp

that from where r they reading the image from

the whole routine is placed there, as i wanted to test several thing and splitting afterwards

OCcore is still not a module but a library, OCBackup and ProcessingTest are using it for core functionality, also OCui uses OCcore

provider->Load("darklab-frame00004.dng", FileFormat::DNG, *_image.get(), *poolAllocator);

Okay. Will try that by directly putting path there , in some time.

hi -- is there anybody here, who is involved in the apertus GSoC process?

mash_: you can assume that somebody is here :)

hmmm... -- i'm quite incertain -- linux programming, camera control and also a little bit of interst in hardware development

I just saw your comment in https://lab.apertus.org/T734

yes -- and i'm quite sure, you know me from other forums and virtual discussions as well... :)

no -- it's not only histograms and waveforms, which i'm interested in... but it's in fact a very important feature if you use tools like natron often for more general purpose tasks

right now i'm for example actualy working on a color calibration plugin for natron, as you may know it from resolve...

but in fact i would be really interested, if there is a chance, to partizipate in the apertus project -- not only in the context of GSoC, but that was the final stimulus to contact you ;)

in fact, i have to say, i'm not a big fan of Google at all! i allways liked to stay independed and establich alternative infrastructure with friend (e.g. mur.at here in graz) to keep them in distance -- so i do nat have an gmail account right now and aren't even able to read the related mailinglist :(

that's fine!

eg aces

and if the beta could capture footage in aces colorspace natively

in practice i always had lots of sympathy for the apertus and allways watched it -- but for may practical work with cameras i had to choose cheaper ready made products...

ACES is nothing spectcular... it's more or less just the standardization of workflows, whiche are very common in tools like nuke/natron ant other OpenColorIO based solutions...

it's the only useful 32bit open source video processing framework ...

i don't konw, if it really makes sense for a camera to export ACES EXRs -- pure raw access and later processing is much more useful!

also keeping bayer data intact

We are thinking about an OpenCine Frameserver though to serve different kinds of formats generated in realtime from the raw file

frameserver through vapoursynth is the current plan: https://lab.apertus.org/T763

i'm just asking, because good libraw support in an openfx generator plugin, taht could be used by many applications would give users more freedom IMHO

BAndiT1983 will be able to share his thoughts about libraw and why he abandoned using it

well it doesn't have to be libraw itself... but i would prefer a openfx over frameservers nowadays.

openfx ist just a plugin lib, frameserver has other purposes and is meant for wider use

not a fan of giving away the control over memory

especially in times of c++11/14/17

yes -- therfor i vote for doing it in RUST! -- it also helps to minimize alle the troubles with buggy plugins! ;)

hmmm -- it's really harde to argue against frameservers... the somehow look very oldfashiond to me, in times, where we try to utilize GPUs as mmuch as possible and minimize cross aplication/hardware transfers...

yes -- you are right! :) it's always easier to have a plausible anser, than to write a working implemenation...

for me the frame server is just a provider of generalized video file, which can be used by every app which supports AVI or similar

how i load videos or process them is up to me

so performance is not the biggest problem

hmm... i think, vor some tasks it doesn't matter if it's a little bit slower, and i like applications that do not require any super expensive hardware to work acceptable

have not seen many applicatios using openfx, so we decided to use frame server for that

the problem is to have enough maintainers for such things, i like new technology, but sometimes one has to settle with mature one as there are not enough people to manage it

but i think, natron could be a really intersting platform to realize the necessary modules with minmal efforts.

maybe, but opencine started 3,5 years ago, so won't kill it off, just because there is already something

*maybe someone

you are right, a few years agao, the situation looked quite differnt... nobody hadd expected, that something like natron could appear.

OC was never meant to be like natron, so it was never in my interest to extend it

forget the question, i'm just rather tired from work

so the client is some video editor or player

maybe, but just a handful of open ones -> https://en.wikipedia.org/wiki/OpenFX_(API)

yes -- there is not much free software around, that supports openfx, but most free video software doesn't support anything beyond 8bit processing as well. :(

my focus is open source, i don't care about professional systems as i don't have the money to buy and use them

it's just the smalest common denominator in actual high end video processing...

how so?

<BAndiT1983> I can view the image , but the display shows only the R channel . Here's the screenshot of it https://drive.google.com/file/d/0B0Xb3WJpS5dFbmE1cDZRT2l0eGs/view?usp=sharing

alright, then i will kill the project and leave apertus project, there is no point in developing it further as there are better professional solutions

i also like free software a lot, and use linux nearly exclusive since the early 90ths, but when it comes to me creative need, i somehow have to satisfy the quality critieria i'm aware of...

no -- don't stop! -- go further! :)

why do you think that open-sourde cannot be done professionally?

i have an engineers degree and work as software developer in my regular job, so i know different sides of things

i really do most of my video editing and grading in a virtual windows machine runing resolve and GPU passtrough.

it's still a closed source application, but now it's availabe without cost on our platform as well.

that's better then nothing!

Ohh . cool . Will do that .

closed source is still closed

that's now changing slowly... many of this applications are now available in some form of training and non-commercial editions too

i relly like to study good foraign software, to make littel things here in linux land better ;)

open source solutions, which do not fullfill your expectations quality wise etc. are no real answer.

!Bertl no i don't like windows so much! ;)

it's just very hard to build software for others in the necessary platform independend way...

yes -- but real issues are usually more related to subtilities, that are hard to solve on all platforms...

cmake loads linux classes or windows ones, depending on the environment

core team is in vienna, i'm on the other hand live in germany

< Britain.

Rex, do you have to bypass a firewall toget on IRC soon when Brexit finishes? ;)

:)

but you can merge with france

... marketing campaigns from the 1700s.

also really interesting connections to france

the only thing I see which strictly isn't correct is the SCL_*/SDA_* connection between the ZYNQ SOC and the MachXO2

but they actually communicate over one or two LVDS pairs

so i2c is "virtualized"?

ops, so sorry will fix this

Elbehery: so best keep the ZYNQ<->MachXO2 connection neutral

Aha, okay

?

ah, alright

shouldn't it be on FPGA side?

Elbehery: it is running in Linux userspace

how fast do you think that a change in fan speed will influence the temperature?

well, I doubt that you need more than one decision per second

BAndiT1983: getting the sensor data from the control daemon is probably way slower than the actual regulation loop

maybe

All clear now :) thank you

nice ideas!

i don't know, if i'm really able to suggest somthing similar useful for the whole project...

most of the ideas i have in mind are not so much hardware related, but more conserning the gaps beteen other existing free software and common used software for artistic work.

https://i.imgflip.com/1m9lyh.jpg

I don't know about tasting photons, but they're slippery and hard to wrangle :)

a good analogy

the floor in Bertls lab it seems

off to bed

good night

Are you on Twitter atoav?

regrade of the tank footage: https://www.youtube.com/watch?v=aEQcOqlCgqQ