Indigo Renderer Forum

An update to Violet. Version 0.1.0-rd, sources attached.

This release includes:

• New phsyically motivated diffraction-limited bloom effect. For best results, try diffraction-limited bloom with linear tonemapping.
  
  Filters have an apply button; tonemapping is always auto-update.
  
  Improved background render that caches output of the render phase in order to allow quick interactive tonemapping.
  
  Generally improved and rationalized layout of controls.
  
  Linear tonemap with exposure (log-linear) and contrast settings.
  
  Various minor bug fixes and improvements.
  
  Merge of some of the dougal2 changes -- noise filters esp.
  
  New and improved histogram.
  
  Added a vs2005 installer project (absolutely required to properly install VC 2005 .EXE files due to new manifest for the C runtime).
  
  Edit controls for sliders.

Still to do:

• Grabbing the histogram at the wrong place. I removed range-clipping from the Reinhard tone-mapper, so that I could get a full-range histogram, which isn't the right thing to do. Range clipping should be performed before collapsing supersamples in the Reinhard tonemapping case.
  
  Contrast adjustments should be centered around top-of-range, instead of the graypoint.
  
  Better minimum-size enforcement for control panels at < 1024x768 needed.
  
  Menu command to switch between horizontal and vertical layout. Vertical layout code is intact, but there's no UI to switch between the two yet.
  
  Tweaks to exploit multi-threading in various places. OpenMP is really very cool. Should make it trivially easy to convert all of the heavy lifting in this app to multi-thread.
  
  Further review of potential dougal2 merges required.

Let me know if there are any issues. I had to back-patch the 2k3 solution files, but they should be ok.

I don't think the 2k3 release settings are right (I had to patch in the file list from the 2k5 project, but can't change the 2k3 options). They should be:

C++/Code Generation:
fast floating point.
favor speed over size
enable use of intrinsics
C++/Preprocessor defines:
add NDEBUG to disable asserts.

I'd be grateful if somebody could do this for me. I've been Vista-ized, and can't run 2k3 anymore. :-/

VC 2005 binaries will follow, but they come in over the 4MB limit. Looking for hosting options right now

Thanks dude, I'll have a look over it soon.

diffraction-limited bloom

What's the difference to simpe gausian bloom?
Is it more accurate? (more physically correct, as you wrote..., but why?)

Great work

Kram1032 wrote: What's the difference to simpe gausian bloom?
Is it more accurate? (more physically correct, as you wrote..., but why?)

In the real world, perfect lenses don't focus perfectly. The sharpness of a real lens is limited by diffraction effects of the lens aperture. In fact, very good quality camera lenses are diffraction limited, and are not limited by defects in the shape of the lens. It actually isn't random defects in the lense that limit how tightly a lens can focus; it's a limit that's imposed by the diffraction pattern of the aperture of the lens.

A discussion of diffraction effects in photography:

http://www.cambridgeincolour.com/tutori ... graphy.htm

The new bloom function convolves the image with the Airy disc. The Airy disc function is a closed form function that describes the diffraction pattern of a circular aperture as calculated using the Fraunhoffer diffraction equations. Strictly speaking, this a simplification. This produces the equivalent of Fraunhoffer diffraction effects in the image, when, in fact, more complicated Fresnel diffraction equations might be more appropriate in some cases. But it's a reasonable approximation that's actually correct for sufficiently distant objects (hence "physically motivated", rather than "physically accurate"). A further simplification is that a real difraction pattern is wavelength sensitive, but this implemenation isn't.

A standard test for lens quality is to focus on a bright point light source, and look for the rings of the airy disc in the image. With a very good lens, the airy disc pattern will be visible.

The results speak more than the reasons why I think it works better on a deep level. The simple answer would be: the new function is a reasonable approximation of focusing artifacts in lens systems and the gaussian function isn't.

Informally, here's what I think the main differences are. The current gaussian bloom implementation leaves steep edges around edges of bright lights. Blending the original image with a guassian convolution definitely isn't the right thing to do. Without bloom, you'll notice that severe aliasing (visible pixels) occurs around the edges of bright lights. The blending approach used by the current Gaussian bloom implementation doesn't eliinate the jaggies at all, mostly because the shape of the falloff around the central disk is too steep, I think. Strangely, and interestingly, when using convolution with the Airy disc, the visible pixels go away altogether. I'm not totally sure why this is, but it definitely has something to do with the rate of fall-of around the central disk, and perhaps something to do with the fact the central disk in the Airy disk is relatively wider and flatter than the gaussian function. Also, I think that the airy disk function has a much wider skirt than the gaussian function. I'd guess that (haven't done the math to support this) the Airy disk function falls off at a rate close to 1/(r^2) outside the central disk, whereas the gaussian function falls of at a steeper rate. Since it's the skirt of the function that produces the majority of the bloom effect, this is important. I was surprised how broad the skirts of the airy disk really are. The bloom from a bright light in an image under reasonable approximations of real world conditions actually extends throughout the entire image. In the image shown above, even the darkest pixels end up being +1/256th because of bloom from the light-bulb-like thing in the image.

With the gaussian bloom function, I think what happens is that the fringes are visibly the wrong density. The blend function is required to compensate for this, but blending causes falloff along the borders of the image to be too steep. So, you're caught between the effects of two artifacts: incorrect density of the fringe, or pixelation of the central image.

The advantage of the gaussian bloom (the reason why I didn't remove it) is that it's much faster, and seems to be able to produce passable results when using Reinhard tonemapping (but not when using linear tonemapping). Although both functions are convolved with the original image to produce the output, there's an optimization that can be performed to calculate gaussian bloom that produces results in a fraction of the time required to do the full general image convolution required by the airy disc function.

Based on the limited set of test images I used, gaussian bloom seems to be better with Reinhard tonemapping -- I think, becaues the Reihhard tone mapping has a big effect on the relatively subtle fringes produced by the diffraction-limited zoom; and diffraction-limited bloom definitely produces better results when using linear tonemapping.

Hmm, interesting that it helps with antialiasing.
btw, do you know if vs2003 supports OpenMP?

I don't think it does. But the interesting thing about the OpenMP implementation is that all you do is add appropriate #pragmas in front of for loops to indicate that the work of the for loop should be spread across multiple processors. The result: perfectly reasonable code for the non-OpenMP case, and perfectly reasonable multi-processor code for compilers that do support it. I've not used it before; but I was surprised now easy, and non-invasive it is to apply the appropriate pragmas for this kind of code (very big array processing operations).

The Fft2d.cpp code has OpenMP pragmas. (The extra for loop in that code actually isn't neccesary; openMP would have split the for loop into top and bottom halves had it been left to its own devices, which would be perfectly good to).

There's #ifdefs around the OpenMP pragmas in the fft2.cpp code if they pose a problem for 2k3 (if they generate warnings, for example). I probably should have done compiler version checks instead of using a #define. (or done it with preprocessor options in the project files). In retrospect.

can we have a binary to play with? .... please

I'm having serious trouble finding a host site. My provider switched over to geocities web hosting since I last used my ISP-provided site, and geocities is brain-dead silly. (4MB/hour download limit, which isn't going to work well for a 4.5MB download; and website names like: http://geocities.yahoo.com/i-am-a-big-s ... @yahoo.com. Who came up with the bright idea of using email addresses in a website URL? Thank god that Google saves us from the Yahoo madness under most circumstances). And very strange that Yahoo will host a 4MB photo for free, but want's $9/month to host a 4MB ZIP file. <eyeroll>.

Re-iterating the plea to the powers-that-be for a temporary (or permanent increase in the maximum upload size of a zip file to 6MB instead of 4MB) so I can upload the binary. - RD Or a request to somebody else who can loan me an hostign site.

one possiblity is to split the zip/rar archive and the other possibility is to use a free file-hoster like rapidshare (www.rapidshare.com).
Looking forward to try this diffraction-bloom-thingy.
thank you for your work rerdavies! also thanks to dougal and ono. you guys are great!

rerdavies --> if you send me the file I can host it for you. just PM me.

great
Do you think, if you'd add the cromatic dispersion to that new blur, would it also give better results in reinhard tonemapping?

(I know, basically, it would extremely increase the waiting time... :S )

[but I can wait]

Kram1032 wrote: great
Do you think, if you'd add the cromatic dispersion to that new blur, would it also give better results in reinhard tonemapping?

I don't think so. I don't really have a firm grasp on why it doesn't work so well with the Reinhard tonemapping. (yet). The end result is that the fringes don't seem to appear as prominently, compared to the same image when using linear tonemapping. I haven't had time to dig into it. Could be that Reinhard tonemapping and bloom are incompatible on a functional level in some way: the purpose of Reinhard tonemapping is to preserve hi-intensity structure; the purpose of the bloom is to obliterate it. (just a theory).

btw, I'll go with the rapidshare solution for now (upload coming as soon as I get home), and resurrect my expired domain name so that i can be in a better position to host any other posts. (takes a while tho). Thansk for the offers.

I see...
yes, that may be a problem.

I once rendered a pic with bloom and after every 2nd uppdate, the overall pic got much darker, than before. Most of the glares did the same, except one: the last one the came, nearly appeared white^^
it looked great, but unusable.
I guess, the standard blendigo settings (didn't look into bloom, for a while now, so that may changed), are kinda unusable