Indigo Renderer Forum

I'm kind of new to subversioning, so bear with me. I have a bunch of enhancements coming that I need to re-merge with current svn sources. Do I actually have rights to update source even with an anonymous login; if not, what do I have to do to get an account?

Things I have that I intend to merge over the next few days.

- A really good histogram that shows values falling over and under range.

- an alternate bloom function, based on diffraction-limited bloom in real lens systems, that provide much better results in conjunction with linear mapping. fwiw, I understand that the bloom functions have ben optimized, and may no longer need auto-update. But this one does. It requires a full image convolution (2d-fft based) , becuase the airy disk function isn't separable; so it's considerably slower than the existing one. so you know.

- Caching of the the bloom/glare/color correction output image, which allows tonemapping operations to always be auto-update: rendering ops use the Auto Update/Apply button; tonemapping operations just do it.

At this point, I'm guessing that sources have divereged enough that I'm going to have a heck of a time merging my updates. Anyway. THought I'd give a heads up in case anyone else is working in this area. That's fine. I consider it a learning experience OSS. Will spend the next couple of days merging with the current branch.

Supplementary question. I have VS 2005, and I have cgwin up and running. I can update makefiles for linux if ther are such things; but updating a vs 2003 DSP (project) file isn't going to be much fun. Anyone have any ideas on the best way to do this. I have a bunch of new files.

And still a bit more work to get some of this stuff into commitable shape.






[/img]

Nice... your updates sound excellent.
Tell me, are you working off the current SVN code?
Or did you start working of dougal2's stuff?
Because he was doing some histogram etc.. stuff that hasn't been merged yet.
As far as SVN writes go, only I have write access (muhaha).
If you post your updated source, then I could have a look at merging it in.

wow - looks really great!

I'm working off svn sources from maybe a week ago (i'd have to check).

Sounds great. Let me clean it up and package it, and I'll submit it for review. Thanks.

wow.
you may as well implement this histogram and other new features - they are beteer than mine.

the only other features that I added were the noise reduction routines, which are in ImageFilter.cpp/h
I can upload these files for you to implement in your version. should be quite straightforward.

rerdavies wrote: - an alternate bloom function, based on diffraction-limited bloom in real lens systems, that provide much better results in conjunction with linear mapping. fwiw, I understand that the bloom functions have ben optimized, and may no longer need auto-update. But this one does. It requires a full image convolution (2d-fft based) , becuase the airy disk function isn't separable; so it's considerably slower than the existing one. so you know.

I known two algorthims that are based on fft, will that be the one implemented in maxwell/fry render? Afaik maxwell/fry render's version is based on the fft of the obstacle/pupil image. The result fft image is then mixed with the original to produced a image with glare.

The fft based method is good for fraunhofer diffraction only afaik but i'm sure will be way better that the existing ad hoc bloom function

It's a re-do, but probably a less general implementation of the maxwell/fry renderer (I haven't seen that): specifically, a convolution with the airy disk function, which is, indeed, the fraunhoffer diffraction pattern for a circular aperture. Rendering of an non-circular iris would produce great result (more or less, the physically motivated implementation of the current glare feature as well as the bloom feature); but I haven't really figured out how to generate a a non-discrete FFT of the iris shape in reasonable time (2D DFT doesn't work at all). For the meantime, it's fixed circular aperture only.

As you point out, there's a lot of approximation in play -- the real deal is wavelength dependent, and might require fresnel diffraction rather than fraunhoffer diffraction. But it's a decent and reasonable and physically motivated procedure that seems to produce good results, *and* it has the interesting side-effect of removing most of the really unpleasant artifacts of truncation of HRD images while converting.

The paper the Maxwell dudes use is probably
"Glare Generation Based on Wave Optics"

Thats what the obstacle/pupil image does. Give a image of a obstacle i.e a camera filter and the pupil image i.e image with a circle, rectangle etc the fft of the image produce the circluar/non circluar aperature pattern you are after

OnoSendai wrote:The paper the Maxwell dudes use is probably
"Glare Generation Based on Wave Optics"

yep thats what i think maxwell/fry render diffraction glare is based upon

FYI http://nis-lab.is.s.u-tokyo.ac.jp/~nis/ ... lare_m.pdf

Dang. Who new this was a publishable result. I've known about this for some time (specifcially that convolution with the Airy disk produces great conversion of HRD images). The hexaganal irises in the examples are a little harsh, but I'm quite certain that something more along the lines of an actual iris shape would produce good reulsts. But yes, this runs along exactly the same lines as the paper you cited. The unsolved issue: how to do non-discrete FFT of an iris image in reasonable time. The airy disk function is a closed form solution of the FFT of a disk, so no continuous FFT was required. Anyway. Let me see if I can get a source commit of what I have, and then I'll give some thought to how to do the general-purpose iris case. Thinking about it, I'm pretty sure I can come up with a decent way to generate the non-discrete FFT.

For what it's worth, on a directly related topic, a formally published anti-patent claim (a great patentable idea that's no longer patentable by me 'cause I published it here).... (I have Microsoft software patents on my mind today for some reason).

I was thinking about this while writing the code. No intention of doing this myself, but I think it would be a great enhancement for Indigo. No warranty as to whether this has already been patented or not; but if it hasn't, consider this a formal publication of the idea, precluding further patents on systems that incorporate ideas described below. <grin>

Date: 5/14/2007. Author: Robin Davies. Ottawa, Ontario, Canada.
What is not claimed:

1. A computer system providing means to render an image, in which the algorithm consists in whole or in part of casting rays from an eye point. and incorporating provisions to vary the angle of the cast eye ray in such a way as to probabilistically simulate the the effects of aperture diffraction effects in an imaging system when successive eye rays are averaged together.

2. The system of claim 1, where the ray deflection is based on closed-form solutions of well-known solutions to aperture diffraction patterns, such as circular aptertures.

3. The system of claim 1, where the PDF of the ray deflection is based on pre-calculated arrays of data, based on numerically calculated solutions to aperture diffraction equations.

4. The system of claim 1, where the PDF of the ray deflection is based on measurements taken from an image of a point light source with an actual phsyical imaging system.

5. The system of claim 1, where the PDF of the ray deflectin is based on measurements taken from a captured image of a light, or other object that has a shape other than a point.


Preferred embodiment:

Aperture diffraction effects have a very visible effect in real-world cameras. It's common for the airy disk of a camera lense to exceed the size of individual pixels in a current-generation digital cameras. This true, for example, for a Nikon D70 digital SLR camera, with a lens aperture setting of about F/8 or greater.

In a MLT-base ray tracer, particularly, but in other path tracers as well, perturb the outgoing eye ray in a stochastic way that simulates the effect of aperture diffraction effects. The diffraction pattern is more-or-less pre-computable. 80% of light falls inside the airy disk of the diffraction, with the remaining 20% spread out over an extraordinarily broad range. The diffusion due to aperture difraction of a very bright point source in an HRD image can impart a visible effect over the entire image. According to my calculations, if the airy disk is 1 pixel in size, the visible halo of a very bright light in the image can easily extend over 400 or 500 pixels from the edge of the light soure.

If convolution is applied on a rendered images, then there a number of (minor) artifacts: very slight vignetting of the image, and failure to account for the effect of light sources that are slightly off the edge of the imaged area, for example.

If diffraction effects are accounted for at render time, then none of these problems occur. Because eye rays may be perturbed so that they travel outside of the boundaries of the directly-visible image, no vignetting occurs, and there is now a possibility that perturbed rays may hit bright light sources outside of the image frame.

This works aprticularly well for an MLT ray-tracer. In terms of an MLT ray-tracer, the pre-calculated image of a point light source that includes aperture diffraction effects can be used to calculate a density function for the perturbed outgoing ray. The extent by which outgoing eye rays are perturbed is modest. For a system in which the airy disk is the same diameter as a single pixel in the generated image, 80% fall within one pixel of where they would without accounting for aperture diffraction; 92% fall within two pixels.

In real world cameras professional-quality cameras and lenses, the size of the airy disk might somewhere in the neighborhood of 1/4 to 2 image pixels, depending on the aperture setting. For cases where there the air disk is significantly larger than a single pixel, resolution of the rendered image of a CG renderer could be reduced without measurable loss in image quality. Thus, for all cases, an MLT renderer could place at least 80%-95% of cast eye rays within one pixel of where it would have gone if aperture diffraction effects had not been taken into account.

In any case, the addition performance imact required to incorporate aperture diffraction effects into an MLT rendering system are not likely to be significantly worse than the effects the DOF has.

This anti-claim is intended to anticipate the case where the stochastic perturbation of the eye-ray is based on any of a number of computational schemes, including, but not limited to: 2D arrays of pre-calcualted numerical data; systems that exploit symmetry in the aperture diffraction pattern, (e.g. separately chose angle and radius in the case of a circular aperture); systems that use data derived from physical measurements of a real-world lens system (e.g. a picture of a bright point light source, taken with a Digital camera).

Attached is my current src tree, which I've called Violet R12 Patch1 beta3.

This package includes:
the source
dev-cpp project file (to compile Mingw/GCC binary)
VS2005 project file/solution
Binaries compiled for:
- Win32 - GCC
- Win32 - VS
- Win64 - VS

Take what (if anything) you need and dump the rest.

I think, for now, this concludes my involvement with Violet development - i defer to superior knowledge in this field (I've started another project anyhow...)

edit: couldn't attach the file, it's hosted here instead:
http://hamsterfight.co.uk/VioletR12P1b3-src-bin.zip (8.5mb)

Well, If that's so, thanks for all your work dougal2, I appreciate it.

yeah no problem at all Ono. robin obviously knows what he is doing, and me less so.
Also, it'll save confusion with the development if my branch ends here.