Sample code was provided for two file formats, TIFF and PPM. In response to a prompt on the lab sheet I tested the location of the origen for the two formats. I put white rectangles around (0,0) in the two types and then used display to see what part of the image had been messed with. For PPM this was the upper left, as I expected from computer graphics before and as display and xv reported. For TIFF, however, this was the lower left. This would make sense for math, but I've thought of the upper left of the screen as (0,0) for long enough that this was enough to set me against TIFF. It didn't help that the image display programs still called the upper left (0,0). I did all of my coding to work with PPM.
I used PNG as well, though only as a display format. To convert my PPM output files to PNG for web-accesiblity, and also to make thumbnails for this page, I used convert which is efficient.
A chromaticity filter that blanks pixels if their red value and their green value are both less than some threshold when divided by their magnitude can remove some of the blue.
The initial images for this project varied widely in background color, though, despite being taken sequentially in the same lighting conditions and against the same background. This is likely due to the flash of the camera being set to auto, as in the images with light blue backgrounds the people tend to look a little washed out. Despite the increased fidelity in human rendering, the lack of a flash and hence an easy to work with blue made processing some of the images moderately difficult. Below are two images for two different students taken sequentially and the results of running that chromaticity filter.and
![]()
![]() |
![]() |
![]() |
![]() |
Applying that filter to the images gives markedly better results:and
and
![]()
![]() |
![]() |
![]() |
![]() |
![]() |
Before deciding on this color pattern I tried some others, but I didn't really like any of them. The smoothness of a colormap with a large number of colors appeals to me greatly, as does the fade from black to red. The alternate coloring of pixels by the number of iterations modulo two is interesting, and I like the Dr. Seuss-like pseudo depth, but it's not as pretty as a smooth fade.
I also implemented jitter sampling, with some number of calculations for each pixel averaged together. For my finished images I used 64 samples for pixel, but they look alright with only eight. Sixty four gives fewer artifacts, though.
The threshold beyond which a complex number is treated as not likely to come back down to zero from is variable at compile time, and is 20 for all of the images shown. To be more efficient I don't actually compute the magnitude of the complex numbers but instead just dot them with themselves and compare them to the threshold constant that way.
If I was going to do more optimization I would likely make one based on symmetry; both Julia and Mandelbrot fractals have a two-way symmetry, though Julia are odd and Mandelbrot are even. This would double rendering speeds.
The Julia set defined by C = < 0.7454054, 0.1130063 > in the rectangle < -1.7, -1.2 > to < 1.7, 1.2 >
![]() |
![]() |
The Julia set defined by C = < -0.285, -0.013 > in the rectangle < -1.5, -1.2 > to < 1.5, 1.2 >
![]() |
![]() |
![]() |