| 01:13 | rton | left the channel |
| 01:54 | TofuLynx | left the channel |
| 02:49 | TofuLynx | joined the channel |
| 02:50 | TofuLynx | changed nick to: TofuLynx|||Away
|
| 02:51 | TofuLynx|||Away | left the channel |
| 02:53 | TofuLynx | joined the channel |
| 03:30 | Bertl_oO | off to bed now ... have a good one everyone!
|
| 03:30 | Bertl_oO | changed nick to: Bertl_zZ
|
| 03:36 | danieel | left the channel |
| 03:38 | danieel | joined the channel |
| 08:29 | aombk | left the channel |
| 08:29 | aombk | joined the channel |
| 09:24 | rton | joined the channel |
| 09:34 | XDjackieXD | left the channel |
| 09:36 | XDjackieXD | joined the channel |
| 10:06 | se6astian|away | changed nick to: se6astian
|
| 10:49 | Bertl_zZ | changed nick to: Bertl
|
| 10:49 | Bertl | morning folks!
|
| 11:40 | TofuLynx | left the channel |
| 11:40 | TofuLynx | joined the channel |
| 11:47 | LordVan | joined the channel |
| 12:18 | anuejn | se6astian: do you know, wether the php stuff in the beta software repo is still needed?
|
| 12:24 | se6astian | its very old
|
| 12:24 | se6astian | and probably doesnt work anymore
|
| 12:24 | se6astian | but probably it does
|
| 12:24 | se6astian | so I wouldnt say its needed
|
| 12:24 | se6astian | but maybe still handy until its replaced properly
|
| 12:26 | TofuLynx | It
|
| 12:27 | TofuLynx | Its okay to suggest a change of a Task detail in my GSoC proposal?
|
| 12:33 | Bertl | sure
|
| 12:33 | Bertl | you can even suggest your own Task for GSoC
|
| 13:16 | Bertl | off for now ... bbl
|
| 13:16 | Bertl | changed nick to: Bertl_oO
|
| 13:17 | TofuLynx | changed nick to: TofuLynx___Away
|
| 13:43 | rton | left the channel |
| 13:45 | rton | joined the channel |
| 14:16 | TofuLynx___Away | changed nick to: TofuLynx
|
| 14:16 | TofuLynx | DrLuke, does openGL have parallelization?
|
| 14:38 | deepak | joined the channel |
| 14:43 | deepak | left the channel |
| 14:58 | sr6033 | joined the channel |
| 15:38 | sr6033 | left the channel |
| 16:25 | LordVan | left the channel |
| 16:25 | LordVan | joined the channel |
| 16:58 | DrLuke | TofuLynx: Define parallelization?
|
| 16:58 | DrLuke | You can't use it from more than one thread if that's what you're asking
|
| 16:59 | DrLuke | otherwise the shader code is running in parallel of course
|
| 17:08 | Bertl_oO | nitpicking here: at least to some degree (depending on the shader units) otherwise sequential ...
|
| 17:10 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 17:12 | BAndiT1983 | why are we discussing optimization even before the code is available?
|
| 17:13 | BAndiT1983 | in my opinion is opengl fine for preview, but for more precision, e.g. for final output, plain code, openmp, opencl or similar is more suitable
|
| 17:14 | BAndiT1983 | normal graphics cards have single-precision and professional one, like nvidia quadro double-precision, normally it describes floating point
|
| 17:16 | BAndiT1983 | to get a solid base, we need some algorithms which are approximating the final output, so the user gets a preview which comes rather close, but we should favor speed there, so resolution could be cut down
|
| 17:17 | BAndiT1983 | LUT (look-up table) is probably the best choice for that
|
| 17:19 | BAndiT1983 | of for now, will be back on later, looking forward to your opinions on that
|
| 17:19 | BAndiT1983 | *off for now
|
| 17:19 | BAndiT1983 | changed nick to: BAndiT1983|away
|
| 17:50 | LordVan | left the channel |
| 18:20 | anuejn | BAndiT1983: what do you mean by more precision?
|
| 18:20 | anuejn | i think that implementing everything twice is not that helpful...
|
| 18:21 | anuejn | BAndiT1983: what does luts have to do with resolution cut down
|
| 18:30 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 18:30 | BAndiT1983 | anuejn, when talking about RAW files, assumption is that they are 48bit ones (3 channels x 16 bits)
|
| 18:30 | TofuLynx | What do you mean by twice, anuejn_?
|
| 18:31 | BAndiT1983 | can you guarantee that you get precise data from pixel shader after retriving the render texture?
|
| 18:31 | BAndiT1983 | and that the graphics card does not some conversions in between
|
| 18:32 | BAndiT1983 | LUT has nothing to do with resolution, but resolution cut down and LUTs are 2 ways to approach "realitme" playback/visualization
|
| 18:32 | TofuLynx | OpenGL 3.3 supports RGBA16
|
| 18:32 | TofuLynx | and RGB16
|
| 18:32 | TofuLynx | so it could at least handle that textures without conversions, I think
|
| 18:33 | BAndiT1983 | as far as i've tested, it worked for one channel only
|
| 18:34 | BAndiT1983 | 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
|
| 18:34 | TofuLynx | and is that a issue?
|
| 18:35 | TofuLynx | you need to display it in some form
|
| 18:35 | BAndiT1983 | that's what i'm asking, if anyone can guarantee that the values are precise after applying the pixel shader
|
| 18:35 | TofuLynx | HMm
|
| 18:35 | TofuLynx | im understand it now
|
| 18:35 | BAndiT1983 | displaying is one thing, but calculating correct values is another
|
| 18:35 | TofuLynx | Dont have the knowledge to answer it yet though
|
| 18:35 | TofuLynx | yeah I understand
|
| 18:38 | TofuLynx | I will research further about the advantages of OpenGL and OpenCL in this case
|
| 18:39 | BAndiT1983 | https://stackoverflow.com/questions/25679626/rendering-on-a-48-bit-rgb-image-using-opengl
|
| 18:39 | TofuLynx | Yeah I saw that page
|
| 18:39 | TofuLynx | but it doesnt answer at all about the calculations
|
| 18:40 | BAndiT1983 | if you look in the comments, there is an interesting question about filtering, which would possibly decrease image quality
|
| 18:41 | BAndiT1983 | in my opinion, the calculations should be pixe-perfect
|
| 18:41 | BAndiT1983 | *pixel-perfect
|
| 18:42 | TofuLynx | hmm, isnt image filtering a displaying thing?
|
| 18:42 | TofuLynx | aka the following step after calculations are made?
|
| 18:43 | BAndiT1983 | 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
|
| 18:43 | BAndiT1983 | it's a bit different to what you do plainly in code, opencl or similar
|
| 18:43 | TofuLynx | hmm :/
|
| 18:46 | BAndiT1983 | just look at the pipeline -> https://traxnet.wordpress.com/2011/07/16/understanding-modern-gpus-1/
|
| 18:47 | TofuLynx | and so
|
| 18:47 | BAndiT1983 | one stuff which i still haven't tried, are compute shaders
|
| 18:47 | TofuLynx | the calculations inside the "black box" can be not perfect
|
| 18:47 | TofuLynx | thats the issue?
|
| 18:48 | BAndiT1983 | the calculations can be perfect, but i'm very sceptical about conversions inside the "black box"
|
| 18:49 | BAndiT1983 | you can try to write a small application which re-uses your code for the challenge
|
| 18:50 | BAndiT1983 | 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
|
| 18:51 | TofuLynx | left the channel |
| 18:51 | TofuLynx | joined the channel |
| 18:51 | TofuLynx | I could try that
|
| 18:52 | TofuLynx | It would be good for me as I would also learn about OpenGL
|
| 18:54 | BAndiT1983 | you can grab some lib to simplify the task with setup, like GLFW
|
| 18:55 | BAndiT1983 | by the way, opencl processing can be very well done on opengl textures, just remembered that
|
| 18:56 | BAndiT1983 | http://www.cmsoft.com.br/opencl-tutorial/openclopengl-interoperation-textures/
|
| 18:57 | BAndiT1983 | also this one has some good overview of compute shaders -> https://www.opengl.org/discussion_boards/showthread.php/180692-OpenGL-Compute-Shaders-vs-OpenCL
|
| 19:21 | TofuLynx | Thanks for the links!
|
| 19:33 | DrLuke | BAndiT1983: OpenGL is as precise as you make it. That means yes, it does pixel perfect operations
|
| 19:33 | BAndiT1983 | also for 48bit data?
|
| 19:34 | BAndiT1983 | the final output of the pipeline should be some clip, DNG foldre or similar with as much range as possible
|
| 19:35 | BAndiT1983 | either we use OpenGL and rely on the shader calculations or we implement calculations in opencl, so they are run in hybrid mode
|
| 19:36 | BAndiT1983 | 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
|
| 19:36 | BAndiT1983 | *merged
|
| 19:37 | BAndiT1983 | 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
|
| 19:37 | BAndiT1983 | *CPU
|
| 19:41 | RexO | joined the channel |
| 19:42 | Rex0r | left the channel |
| 19:43 | RexO | left the channel |
| 19:43 | RexOrCine | joined the channel |
| 19:48 | Rex0r | joined the channel |
| 19:48 | RexOrCine | left the channel |
| 20:23 | anuejn | BAndiT1983: why do you want to get 48bit ints into the shader?
|
| 20:24 | anuejn | anyways, you can use float32 textures and have no problems with bit depth?!
|
| 20:25 | TofuLynx | Bandit wants 48 bits int because it's 16 bits per pixel
|
| 20:26 | anuejn | and there are those 16bit per component textures, which are also enough
|
| 20:27 | anuejn | TofuLynx: but why do you want to pack 3 sensels into 1 texel component?
|
| 20:28 | TofuLynx | I don't know, I don't know anything about openGL neither openCL
|
| 20:30 | BAndiT1983 | float gets converted by GPU, this is possible problem number one in that case
|
| 20:31 | BAndiT1983 | i want to input 12bit data and get linearized, gamma applied, 48bit at the output
|
| 20:31 | anuejn | ok why?
|
| 20:31 | BAndiT1983 | why what?
|
| 20:31 | anuejn | why is it problematic for you to do the math in floats?
|
| 20:32 | BAndiT1983 | i said it above, the single-precision of normal graphics cards could make problems
|
| 20:32 | anuejn | but 32bit >> 12 bit?
|
| 20:33 | BAndiT1983 | 12 bit per channel
|
| 20:33 | anuejn | yes
|
| 20:33 | BAndiT1983 | you have 36 bit, but this are often packed by log or something in that direction, there are many different technics out there
|
| 20:34 | BAndiT1983 | using opengl is ok for preview, but not for serious computation with all the colorspace conversions, linearizing, gamma etc. etc. etc.
|
| 20:35 | anuejn | we could do (116bit int texture) -> shader -> (3 32bit float texture)
|
| 20:36 | BAndiT1983 | try it first, if it really works that easy
|
| 20:36 | anuejn | it doesnt matter, wether you do all the floating point math in opengl or opencl
|
| 20:36 | BAndiT1983 | and try to get the data from GPU buffer back to the disc
|
| 20:37 | BAndiT1983 | https://stackoverflow.com/questions/7907510/opengl-vs-opencl-which-to-choose-and-why
|
| 20:38 | BAndiT1983 | precision is making the difference
|
| 20:39 | BAndiT1983 | but you can prove me wrong, just develop a simple app which does the conversion and puts out an image file with 16bit
|
| 20:39 | BAndiT1983 | which comes straightly from GPU
|
| 20:39 | BAndiT1983 | 16bit per channel
|
| 20:44 | anuejn | will try :)
|
| 20:50 | BAndiT1983 | anuejn, try to implement also a simple profiling, so you can check how long does it take to run it for single image
|
| 20:50 | BAndiT1983 | then it can be estimated if it is sutiable for realtime
|
| 21:14 | TofuLynx | left the channel |
| 21:20 | TofuLynx | joined the channel |
| 21:21 | BAndiT1983 | changed nick to: BAndiT1983|away
|
| 21:21 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 21:40 | se6astian | off to bed
|
| 21:40 | se6astian | good night
|
| 21:40 | se6astian | changed nick to: se6astian|away
|
| 22:23 | TofuLynx | left the channel |
| 22:23 | TofuLynx | joined the channel |
| 22:23 | BAndiT1983 | changed nick to: BAndiT1983|away
|