END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

This is weird. I was experimenting with UF5 and found this:

1. I have a direct coloring formula set all pixels to red 64/255, with a pattern in green, blue, and alpha.

2. I export the image as a png with transparency.

3. I examine the image in Photoshop. The eyedropper tool reveals that the pixels have red = 64 (on a scale of 0 to 255 there).

4. I have a formula with an image parameter that takes trunc(255.0*red(col)) from the color of the image pixel corresponding to the screen pixel, tests it for being a specific value, and produces wildly different colors based on the other components depending on whether that test returned true or false.

5. The pattern appears correctly when the image exported in 2, above, is selected.

6. However, if the test value is set to 64, nothing happens. The colors change if the test value is instead set to 53. I conclude from this that a red byte of 64 generated by formula correctly produces a red value of 64 in the (losslessly compressed) png exported, but that a red byte of 64 in an image parameter is changed to a red byte of 53 in the read-in image.

7. I change the fractal to use the standard Pixel formula and standard Image coloring, selecting the same png as the image parameter for the latter.

8. The image looks more or less as expected. I export it as a png with transparency.

9. I examine the second png in Photoshop. One particular pixel has red 53, green 0, blue 9 where the corresponding pixel in the first png has red 64, green 0, blue 12.

This seems to confirm that pngs do not round-trip correctly through Ultra Fractal. In particular, if you have an MxN png, create a blank MxN fractal, set the formula to Pixel, set the outside coloring to Image, set the image to the png, and export the result as another png, you get a png that is darker than the first png, as if a gamma correction has been applied unrequested by the user.

Windoze Vista. But I don't think "decodes PNGs accurately and without distortion" is supposed to be a platform-specific feature ...

Actually, it's quite surprising that this happens at all. There is a good, well-supported, free cross-platform png library (naturally just called "libpng") for C/C++ that you'd think would be the first choice in a native application on either OS and that you'd think would be well-tested enough by now to definitely produce an in-memory raster pixel with a red byte of 64 when fed a png with a red byte of 64.