3dickulus
|
|
« on: August 05, 2015, 04:28:09 AM » |
|
Has anyone looked at this as a way to speed up Fragmentarium (or other FF render engines) Ray Histogram Fusion http://www.ipol.im/pub/art/2015/119/from what I understand you can get an image that looks as good as 200 samples from 20 samples, (the included tests bear this out) I have been looking at this source code and it seems pretty straight forward from a coding standpoint, render image, record histogram data while rendering, process through filter. edit: or am I late for the show
|
|
|
Logged
|
|
|
|
Patryk Kizny
|
|
« Reply #1 on: August 07, 2015, 10:16:21 PM » |
|
Curious about the progress. Would that be work on the front/back buffer processing or something to implement on the GLSL side?
|
|
|
Logged
|
Visual Artist, Director & Cinematographer specialized in emerging imaging techniques.
|
|
|
3dickulus
|
|
« Reply #2 on: August 08, 2015, 02:12:49 AM » |
|
the paper I linked to, above, explains the process in detail, provides 3 algorithms and sourcecode, the histogram collection part is in pbrt, a raytracer program, basically, collect histogram data while rendering, save rendered image, save histogram file, apply filter using image and histogram as source, save new image I also found source code for a parallel version of the filter part but the histogram data has to be collected while rendering, still studying the code... it does require a lot of memory but if it can work on tiles and write the histogram data to a file instead of keeping it all in memory it should be manageable on the average desktop box
|
|
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #3 on: August 09, 2015, 03:36:30 AM » |
|
Curious about the progress. Would that be work on the front/back buffer processing or something to implement on the GLSL side?
DE will have to record an array of histogram data for each pixel, unless the data can be generated from the rendered image somehow... still studying the code.
|
|
|
Logged
|
|
|
|
Patryk Kizny
|
|
« Reply #4 on: September 01, 2015, 02:51:36 PM » |
|
Did you leave it or still playing with that?
|
|
|
Logged
|
Visual Artist, Director & Cinematographer specialized in emerging imaging techniques.
|
|
|
3dickulus
|
|
« Reply #5 on: September 02, 2015, 03:12:43 AM » |
|
the data is stored in an EXR image as layers so I'm mucking around with EXR, it works (EXR) perfectly on lin and I have almost got it to compile on win except for 4 thread functions that exist in the library but don't compile on win, so close. once I get EXR going on windows I will start testing RGBZ files and histogram layers, it would be nice if a Windows brainiac would help out... anyone?
after playing with EXR images I totally see what you mean, they look richer and deeper.
|
|
|
Logged
|
|
|
|
eiffie
Guest
|
|
« Reply #6 on: September 02, 2015, 09:19:00 PM » |
|
Which thread functions? I usually use winapi functions in their place. - CreateThread, ExitThread
|
|
« Last Edit: September 02, 2015, 09:30:17 PM by eiffie »
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #7 on: September 03, 2015, 05:33:38 AM » |
|
it seems odd to me that the OpenEXR lib and tests compile, run and pass, but when I go to the next step, compile Fragmentarium and link with static OpenEXR, it fails, the source is the current zip file on my website and compiles and runs on linux there is a mingw flag -mthreads for the gcc compiler... https://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-OptionsSupport thread-safe exception handling on `Mingw32'. Code that relies on thread-safe exception handling must compile and link all code with the -mthreads option. When compiling, -mthreads defines -D_MT; when linking, it links in a special thread helper library -lmingwthrd which cleans up per thread exception handling data.
...I haven't tried this yet. the OpenEXR configuration scripts account for different thread handling conventions and uses different files from ilmbase-2.1.0/IlmThread/*win32.cpp when compiling on win I think it's my lack of proficiency with windows and some flag or setting isn't quite right, as I said, OpenEXR compiles and passes tests, the failure is in the linking part with Fragmentarium
|
|
« Last Edit: October 09, 2015, 05:33:52 AM by 3dickulus »
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #8 on: September 03, 2015, 03:39:49 PM » |
|
@eiffie it's in the ThreadPool calls iirc, I will have some time over the weekend to sit down and try again. update: fixed it, combination of -mthreads -lmingwthrd -lz -lzdll.lib not sure why mingw needs to link it's own static libz.a AND the windows static zdll.lib but it seems to work now update2: no zdll.lib dependancy, compiled/linked EXR as static
|
|
« Last Edit: October 09, 2015, 04:33:11 AM by 3dickulus »
|
Logged
|
|
|
|
Crist-JRoger
|
|
« Reply #9 on: October 08, 2015, 06:03:43 PM » |
|
@3dickulus speedup Fragmentarium? Really?
|
|
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #10 on: October 09, 2015, 04:41:02 AM » |
|
Yes! at least I think it would get 200+ iteration quality from 20 iterations, the link in the first post is to a paper published @ IPOL 2015-03-11
this image shows input (left), single (mid) and multi (right) scale passes
Dragon model from the Stanford 3D Scanning Repository
|
|
« Last Edit: October 09, 2015, 05:52:15 AM by 3dickulus, Reason: img »
|
Logged
|
|
|
|
Crist-JRoger
|
|
« Reply #11 on: October 09, 2015, 12:45:35 PM » |
|
@3dickulus sorry for my bad english. I meaned how it works in fragmentarium, how enable it in fragmdntarium. I thaught you tried this...
|
|
|
Logged
|
|
|
|
3dickulus
|
|
« Reply #12 on: October 09, 2015, 03:01:41 PM » |
|
No, I haven't tried it yet hoping someone with bigger math brain will help.
|
|
|
Logged
|
|
|
|
|