An important practical aspect of anti-aliasing
JackOfTradeZ, et al, I forgot to mention an important practical aspect of anti-aliasing-type image manipulation! If you start with a 256 value color table-type image (like a GIF) and resize it, then if your image manipulation program uses an internal image format the same as that original image (color table-type, for a GIF in my image program) and/or you write out a color table-type image, the results of your anti-aliasing will be quite poor. The 'averaging'/filtering of neighboring pixels' color values during resizing will essentially always result in a color value *not* in the source image's color table. If the resizing algorithm or output image is required to use the original input image's color table colors only, the algorithm can't use its calculated color values that are 'between' the values in that image's color table -- as is necessary to provide anti-aliasing. I work around this problem by first converting my .GIF images to JPG format, and then resizing *these* images down in size to start my anti-aliasing process. The 24 million color format of JPG can then better represent the output of the resizing filter. And I also write out the resulting final resized image in .JPG format to preserve the algorithm's use of the wider range of colors. Note that converting the original input GIFs to the same-sized JPG images retains the identical colors as are in the original GIFs. Also, the JPG 24 million color format gives the ability to represent the needed 'in-between' colors that are not in the original GIF's color table. These 'in-between' colors are created when the averaging/filtering algorithm calculates them during the resizing. I have some more material about anti-aliasing on the bottom of my home page: http://www.emarketingiseasy.com/TESTS/FOTD/jim_muths_fotd.html One of the most important things I figured out about anti-aliasing was this... Excerpt: "One thing that anti-aliasing can do to a fractal is shift the overall brightness of the color of an area that has many single, contrasting pixels in it. Initially, I was unhappy that this happened, since the original colors of the single pixels had been altered, thus shifting the appearance of the area's overall color noticeably. However, on closer investigation I realized that this decrease in contrast of scattered single pixels in an anti-aliased image actually displays the underlying fractal more accurately. Here's why -- quite often the feature in the fractal that's being shown as a single bright pixel is much smaller than that pixel. So, displaying that tiny feature as an entire pixel of that one bright color gives that tiny feature a visual emphasis much greater than it should actually have. As an example, if a feature is in a color that contrasts with that area's background color, and is approximately one tenth the area of a single pixel on the display  but, by chance that tiny feature is sampled by Fractint  then that entire pixel would show that contrasting color. The nine tenths of the fractal in the pixel that are of the background color are not seen when this happens. Anti-aliasing adjusts the pixel's color towards the background color, to better reflect the tiny feature's true impact on the pixel that it's displayed in." Another way to say what's going on is: Averaging or filtering a tiny feature's color with its neighbors correctly de-emphasizes that feature. When that tiny feature is displayed as a single pixel, it's being shown as an area much larger than it actually is in the underlying fractal. Note that the single, isolated contrasting pixel color in the original image is not an incorrect color value for that exact location in the fractal. The regularly spaced sampling of the underlying fractal in a raster pattern for each pixel has simply hit a tiny (much smaller than a pixel) bright feature within a larger, darker area by chance.
I made an animation at 2048x2048 recently - 1st time at that resolution, using the Disk-video mode.
When I compile the frames to video at lower resolution, now the video looks much "cleaner"
One can choose how many neighboring pixels are used in the resizing used for anti-aliasing. [The factor by which one reduces the size of the image.] It's a personal choice, rather than what's 'correct.' If I recall correctly, different people in this forum use nine, 16 and 25 neighboring pixels -- and different filters. I use 16 neighboring pixels and the Lanczos filter, and I'm pretty happy with my results. This means that I have to calculate my images four times larger in both X and Y to get my 16 pixels, so 4k x 3k pixels will produce a final image of 1k x 768 pixels downsized/filtered by a factor of 4. Note that downward resizing can have a 'softening' effect on the fractal's features due to the removal of high spatial frequencies. I counter this by following my resizing with a *very* slight sharpening of the image. I choose a value that's not visually noticeable, but does remove the original slight fuzziness of the resized image. - Hal Lane ######################## # hallane@earthlink.net ######################## --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com
Am 17.01.2015 um 05:53 schrieb Hal Lane:
I forgot to mention an important practical aspect of anti-aliasing-type image manipulation! Here is a new link for both versions of the Mandel Miracle. For comparison use the downloded versions only. After the new and hopefully latest MFR_13 update the GIF version generates in 24 instead of 35 Minutes and is absolutetely identical. The anti-aliased version is the JPG version. Using the Irfan Viewer 1280/1024 you can switch with left/right button. ; https://www.dropbox.com/sh/lp8t3ud92pej5va/AABLIbskVw3o2GrS1dvwDPTNa?dl=0 ; Petta
participants (2)
-
Hal Lane -
Niekamp