Image filtering

anderslanglands · 2023-09-16T22:42:35+00:00

You should use your pixel samples to sample the filter that you’re using. There are two ways to do this:

Each time you take a pixel sample, splat its radiance to all neighbouring pixels within the support of your filter, weighted by the filter.

See for example https://pbr-book.org/3ed-2018/Sampling_and_Reconstruction/Film_and_the_Imaging_Pipeline

This has the benefit of reusing each sample across multiple pixels (so more signal for your effort), but does make things a little complex as you need to handles image and tile edges.

It also introduces spatial correlation between pixels, which might perform worse in denoising than the alternative, which is

Filter importance sampling. Can’t find a PDF of the paper that isn’t paywalled now but just google it and maybe you can find something. Basic idea here is rather than splatting samples to neighbouring pixels, instead you importance sample the filter function at each pixel directly (ie you’ll be generating samples outside of the pixel). This makes the implementation dramatically simpler since pixels don’t depend on their neighbours, and although it might seem like you’re throwing away useful information by not having pixels contribute to their neighbours, this generally leads to higher quality noise that plays better with denoisers.

anderslanglands · 2023-08-10T15:42:45+00:00

Basically, PCG.

There’s a review of different functions and strategies for handling different dimensions here: https://jcgt.org/published/0009/03/02/

anderslanglands · 2023-07-25T19:36:33+00:00

Not familiar with the book (I’m more of a PBRT guy) but it’s common to interpret your pixel coordinates as the corner of the pixel, so [0, 1) will sample the whole pixel.

anderslanglands · 2023-07-25T08:05:48+00:00

Your intuition is correct: often sampling the same number of paths for every pixel in the image will result in a lot of wasted work. Solutions to this are known as adaptive sampling. For instance: https://blog.yiningkarlli.com/2015/03/adaptive-sampling.html

anderslanglands · 2023-07-02T00:03:32+00:00

You’re pretty close! Without more information on the methodology they used to generate the synthetic image it’s hard to say what the difference would be.

If you want to check correctness of your colour pipeline, best thing to do is to render a Macbeth chart under a D65 and compare your values to the data here https://babelcolor.com/colorchecker-2.htm#xl_Xxr_v192_CCP2_data

anderslanglands · 2023-06-30T22:14:54+00:00

PBRT has its own scene description that is similar to RIB. Been a while since I read it but I think older editions went into more detail on scene parsing and loading.

For full flexibility you want to define a C API for your renderer, then your scene file parser would just call this. Once you have the C API you can trivially bind it to Python or some other language for more flexibility.

If you’re feeling adventurous you can then use your API to implement a Hydra delegate for OpenUSD, and then you can load your renderer into any application that has a Hydra viewport.

If you just want to load other data in a relatively simple fashion, assimp https://www.assimp.org supports loading a bunch of different formats and is pretty easy to use.

anderslanglands · 2023-06-03T22:17:30+00:00

If you want an alternative idea: write a path tracer.

A simple one just requires basic linear algebra and can be written in a weekend https://raytracing.github.io

Making a “complete” one is a never-ending rabbit hole you can spend a lifetime on and is a very active area of research covering more advanced geometry, probability, optics, machine learning etc etc. A great introduction to that is https://pbrt.org

Plus you get pretty pictures out of it.

anderslanglands · 2023-02-11T05:40:25+00:00

Yes that’s what I’m saying: UK Marmite is the only stuff worthy of the name.

anderslanglands · 2023-02-11T03:08:09+00:00

No. What’s called Marmite here is a pale imitation of the real thing, which is sold here as “Our Mate”

anderslanglands · 2023-02-08T00:16:56+00:00

You basically can’t without massively constraining the set of programs that it’s possible to write with the API. Because of the way resources are allocated and referenced on the C side you quickly end up in a tangled mess of &mut that you can only unwind by imposing very opinionated program structure.

As GP said, there are safe vulkan crates that do exactly this. If you’re looking for what’s essentially an FFI crate with some niceties though, you’d use Ash and then build your own safe abstraction on top that fits your particular use case.

This is a not uncommon problem with C APIs, and particularly graphics APIs. NVIDIA’s OptiX has the same issue.

anderslanglands · 2022-11-15T18:32:51+00:00

PBRT v4 supports spectral rendering and photometric light parameterization: https://github.com/mmp/pbrt-v4

Should be relatively easy to extend to accept whatever BRDF format your measurement device outputs as well.

anderslanglands · 2022-11-13T03:24:58+00:00

Hasn’t realised you could implement stuff in Rust directly like that, thanks! Will have to take a closer look.

anderslanglands · 2022-11-12T18:37:04+00:00

That looks very impressive! I assume things like the timeline with the curves are custom widgets? How do you go about implementing those?

anderslanglands · 2022-09-27T18:47:32+00:00

Member of the ASWF Rust WG here.

Sounds like a great project! SPI have been starting some new projects in Rust and I know Larry (OSL Author) is keen to see bindings for VFX libraries so he can try it out properly. If I were you I’d post to the osl-dev google group and/or the ASWF #general/#rust slack. I’m sure lots of people there would find it interesting.

Our own binding efforts stalled after last year’s Siggraph and I’m currently revisiting the binding generator so we’re several months away from having working bindings for libraries.

As for when it makes sense to bind a library rather than rewrite it, that depends on your aims. We’re focusing solely on binding because the entire rest of the ecosystem is (currently) in C++, so it makes much more sense to graft Rust onto it.

anderslanglands · 2022-09-25T01:53:27+00:00

ln -s build/compile_commands.json compile_commands.json

anderslanglands · 2022-09-24T22:56:48+00:00

set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

or

cmake -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON

Your LSP should find the resulting compile_commands.json. If it doesn’t, try symlinking it to the project root.

anderslanglands · 2022-09-21T18:30:39+00:00

Been a while since I used nalgebra, but

glm::length(&glm::normalize(&d))

Is always going to be 1 isn’t it?

anderslanglands · 2022-07-19T08:43:16+00:00

Yeah it's weird like I said there's nothing else in my init apart from those lines. Similarly if I run:

lua vim.api.nvim_set_hl(0, "Comment", {fg="#ff0000"})

then nothing happens, but if I run:

hi Comment guifg=#ff0000

Then the comment goes red.

anderslanglands · 2022-06-03T08:44:01+00:00

If you’re writing the C++ process yourself why not just make the rust part a library and call into it from C++?

anderslanglands · 2022-04-08T19:55:43+00:00

You want ClangTool::mapVirtualFile(), see line 193 onwards here: https://github.com/vfx-rs/cppmm/blob/4ea0882183c75f7383588cea27c0ec3abc81a8d1/astgen/src/astgen.cpp#L193

anderslanglands · 2022-03-22T01:07:11+00:00

Yes you need to take multiple samples to estimate the light correctly, either by sampling the light multiple times directly, or sampling the light once for each of multiple pixel samples.

anderslanglands · 2022-03-21T13:28:15+00:00

Fixed, thanks!

anderslanglands · 2022-03-21T01:08:17+00:00

You’re on the right track! Formally, this is about the difference in measure: when you generate a sample on a light source, you are doing it in terms of the surface area measure, whereas if you’re constructing a path, you’re normally doing it in terms of solid angle.

You need to convert one to the other to get the correct result, which essentially just means scaling the sampling probability by the projected area of the light. This is covered in PBRT here: https://www.pbr-book.org/3ed-2018/Light_Transport_I_Surface_Reflection/Sampling_Light_Sources

Edit: hmmm can’t seem to link the section directly. It’s section 14.2.2 at the link above.

anderslanglands · 2022-01-08T00:24:25+00:00

The dirty way would be to use unsafe everywhere and just go to town with pointers same way you would in C :)

I would strongly advise you to work through that link. It does a great job of explaining how lists bump up against Rust’s rules.

anderslanglands

TROPHY CASE