#apertus IRC Channel Logs

morning folks!

se6astian: do you know, wether the php stuff in the beta software repo is still needed?

and probably doesnt work anymore

so I wouldnt say its needed

It

sure

off for now ... bbl

DrLuke, does openGL have parallelization?

You can't use it from more than one thread if that's what you're asking

nitpicking here: at least to some degree (depending on the shader units) otherwise sequential ...

why are we discussing optimization even before the code is available?

normal graphics cards have single-precision and professional one, like nvidia quadro double-precision, normally it describes floating point

LUT (look-up table) is probably the best choice for that

*off for now

i think that implementing everything twice is not that helpful...

What do you mean by twice, anuejn_?

and that the graphics card does not some conversions in between

OpenGL 3.3 supports RGBA16

so it could at least handle that textures without conversions, I think

graphics card still convert to dislpay the final image, as the displays are usually 8bit, not taking 10bit displays into account, as they are not widespread yet

you need to display it in some form

HMm

displaying is one thing, but calculating correct values is another

yeah I understand

https://stackoverflow.com/questions/25679626/rendering-on-a-48-bit-rgb-image-using-opengl

but it doesnt answer at all about the calculations

in my opinion, the calculations should be pixe-perfect

hmm, isnt image filtering a displaying thing?

you are pushing data to GPU and retriving it after calculations back, but GPU is at some points a black box, so we need verification, that the retrieved data isn't adjusted by some filter setting, texture format and so on

hmm :/

and so

the calculations inside the "black box" can be not perfect

the calculations can be perfect, but i'm very sceptical about conversions inside the "black box"

the code has to be adjusted to get at least the 12bit, without the conversion to 8 bit, the you could send it to the GPU, process through pixel shader, something rather simple, so you can verify the numbers, retrieve the result and compare to expected one

It would be good for me as I would also learn about OpenGL

by the way, opencl processing can be very well done on opengl textures, just remembered that

also this one has some good overview of compute shaders -> https://www.opengl.org/discussion_boards/showthread.php/180692-OpenGL-Compute-Shaders-vs-OpenCL

BAndiT1983: OpenGL is as precise as you make it. That means yes, it does pixel perfect operations

the final output of the pipeline should be some clip, DNG foldre or similar with as much range as possible

haven't succeeded in getting 48 bit into shaders, so i've implemented a shader with 3 separate textures, each 16bit, to apply data separately, then it is metged together in shader for display

what i haven't tested is the retrieval of data from GPU to the CPU again, as debayering and conversion are currently done on SPU

BAndiT1983: why do you want to get 48bit ints into the shader?

Bandit wants 48 bits int because it's 16 bits per pixel

TofuLynx: but why do you want to pack 3 sensels into 1 texel component?

float gets converted by GPU, this is possible problem number one in that case

ok why?

why is it problematic for you to do the math in floats?

but 32bit >> 12 bit?

yes

using opengl is ok for preview, but not for serious computation with all the colorspace conversions, linearizing, gamma etc. etc. etc.

try it first, if it really works that easy

and try to get the data from GPU buffer back to the disc

precision is making the difference

which comes straightly from GPU

will try :)

then it can be estimated if it is sutiable for realtime

good night