Rick,

Tell you what. Any site you think can prevent me from capturing the images, without requiring some funky computer-compromising plugin or viewer to be installed(*), you send me the link and I'll send you the pictures. That includes your only-shows-full-size-when-mouse-hovers site; I can just read the JavaScript source code and get the URL for the images myself, piece of cake.

--Damien

(*) I qualify this because a few people have suggested that you only make your images available in a custom, proprietary format that requires a special browser plugin to view, and that plugin when it runs tries to disable a bunch of stuff on the user's system that might be used to copy the image. This is a really stupid approach, because (a) 90% of your visitors won't download the plugin, so they won't see your art, and (b) the plugin probably only works on Windows, and only in Internet Explorer, so you just blew off another 25% of your visitors, (c) requiring users to install system-crippling software to see your art is really presumptuous, and (d) you still can't prevent someone with a debugger from getting your artwork, although you sure as hell made it harder for anyone to see it, not just hackers.

After examining both the formulas and the parameters, it's clear the problem is in the dac010 formula, which relies on #width and #height in its calculations. This is almost always a serious problem when trying to render images larger. You can either write to the author (David Cherry) and try to get a fix, or you can find another formula which does essentially the same thing, but scales properly.

Unfortunately it's not often clear, without looking at the formula source code, whether or not an untried formula will properly scale. It's certainly possible to use #width and #height in a formula in "correct" ways that will scale properly, but many of the people who write formulas aren't thinking about large-size images when they write, they're just writing to try out an idea. So unless you know what to look for, it can be hit-or-miss. This is a general, recognized problem with UF, since there are now so many formulas in the database.

--Damien

Rick,

Realistically, there is absolutely nothing you can do to prevent an image from being copied. There is no right-click prevention script, no magic HTML markup, nothing that will prevent your image from being stolen. Please understand: you cannot prevent "Save As". Truth be told, if you're using the same watermark in all your images, a determined thief can use that to reverse the watermarking process. That's why digital watermarking algorithms include a randomizing element, but those too are not perfect.

I have in the past had people literally airbrush my marks right off an image and have them posted back to the same forum.

So if you want to blast dA for their policy--and there is plenty of basis for doing so--go right ahead. But please don't suggest they should waste their time with ineffective image-saving prevention schemes. Anyone who suggests they have a way around it is selling snake oil.

--Damien

I just posted these this evening. Took me a while after I got back to have enough time to stitch together all the panoramic photos.

http://www.fractalartcontests.com/2006/exhibit.php

Mags and I have traded apologies and forgiveness has been granted to each... sorry for the ruckus, folks.

I already provided you with this information on a public post to the UF list on July 7:

"It turns out there were some technical issues with your images, and that
means yes, your images were not viewed by the contest panel. That is
unfortunate, and I'm sorry it happened; I am not an infallible machine and
occasionally I do make mistakes. Your entries are now displayed on the
contest site."

To which you replied an hour later:

"Well, at least I got a quick reply this way!!  Thank you for at last
displaying my entries.  I was never complaining that they hadn't been
selected - I never thought they would be in the first place and said so to
you - your reply was that you thought they had a good chance."

I guess that's why I'm surprised that you still maintain you were never told, or that I ignored your email.

--Damien

Again, Mags, I am forced to answer you on all forums.

Just "spreading the word" about things that have not been substantiated, a conclusion you jumped to without facts and without attempt at clarification. That's not just an accusation, that's an unfounded accusation.

Link to thread on FracFan forum where I outline how what you say constitutes an accusation

No one else got invited because the sponsors elected not to invite anyone else. Just because someone else was suggested but not invited does not mean they were ignored; that's you putting a spin on it. What it does mean is that they weren't invited.

I don't think you'd even be breathing a word right now about any of this if your work had been selected. But it wasn't, because technical problems prevented you from uploading your work directly to the contest site, and when you sent your work to me, I didn't properly get it inserted into the contest system. Therefore your submissions were not considered. That's a regrettable mistake. But that doesn't mean your current campaign is reasonable.

--Damien

Mags,

Since you seem to have now raised this issue in three separate discussion forums (of which Renderosity's is the third), I am compelled to answer you in each one.

The selection panel did not invite themselves. The sponsors and organizers asked ten of them to choose one of their own images for the exhibition, as part of the invitation process; one of those asked declined. No one else got invited.

I don't realistically expect you to apologize for your accusations, but it would be appreciated. I'm more than a little bit offended by your behavior, and that's quite an accomplishment, as I don't get offended easily.

--Damien

I've rendered some very large images. Most of the time when I finish an image, I render a 4,000-pixel version in UF, with one level of anti-aliasing (effectively, 12,000 pixels on the longest side). Since I print these at 200ppi, this is enough for a 20" print, and that's what I sell most often.

Occasionally, though, I will render larger. I have done a 48"x18" print at 400ppi (special request), which when you factor in the anti-aliasing works out to be 57,600 x 21,600 pixels. I once prepared a 7'x5' (yes, feet) image, but that was only 150ppi, so it was only 37,800 x 27,000. And for the ICM exhibition in Spain I did a couple at 12,000 pixels, so the effective size was 36,000 x 18,858.

The amount of time it takes to render any image is going to depend on how fast your computer is, how fast your software is, and how demanding your image is. The image I just uploaded took nine and a half hours to render at 4,000 (12,000 when you count the AA). That's using Ultra Fractal 4 and five computers, about 15GHz of power total. (I should add my wife's new laptop... wonder if she'd object...) But to do that render, I had to interrupt another render that's been going for... 590 hours, and has 919 hours to go. Rykk loaned me the use of his farm for a bit to help out with the long render, but it's still going to be a few weeks before it's done. This is the longest render for me so far, topping my previous 900-hour record (that I can now render in 100 hours due to upgraded computers).

That's another thing that I've noticed. My newer images almost always take longer to render than my old ones. I recently sold a print of a ten-year-old image; back when I made it, it took hours to render a 1,024 x 768 version, and I had to assemble the layers by hand afterwards. Now I can render the entire thing at 8,000 x 6,000 with full anti-aliasing (effectively 24,000 x 18,000) and the entire job is done in nine hours, automatically assembled. That's a 500-fold increase in speed, or roughly doubling in speed every year. Moore's Law was never so sweet.

For the most part, when I make an image I'm aiming for 10-20 hours to render the 20" print size. That means staying away from some formulas or settings on formulas that are too slow, unless I'm in a serious tinkering mood or the image absolutely doesn't work any other way. The most annoying thing is when I discover I've got a particular effect that requires heavy anti-aliasing to render properly; the 100-hour render I referred to above required two full levels of anti-aliasing to render properly, for an effective resolution of 36,000 x 27,000. And it was slow as mud to begin with.

Ten years from now we'll wonder at the simplicity of the fractals we're creating today.

Rick,

Your video card won't make a scrap of difference in how fast either Photoshop or Ultra Fractal responds, unless you purchase one made in 1995. Things getting sluggish when you have a mega-layered image is entirely due to RAM and CPU.

On the other hand, there are plenty of games that will benefit from a mongo video card, so if gaming is your thing, by all means indulge. Just watch out for those MMOs, they eat time even worse than fractals do.

--Damien

I guess there's one other thing to point out, something I thought about mentioning back when we were talking about color control in UF. While it's true that UF does not have the same kinds of color control you have in Photoshop, there are still things you can do with "color adjustment layers" that allow you to globally tweak the colors of all the layers underneath them. I often use these to brighten, darken, saturate, hue-shift, or color cast entire images all at once. I had a nice write-up of it somewhere but it's not right in front of me. The basic technique is pretty simple, you just slap a layer of solid color onto an image, and choose the merge mode to obtain the desired effect. Then you adjust opacity to taste.

white + overlay = boost contrast

black + normal = darken

white + normal = wash out

(HSL: 0/128/128) + HSL Add = no change, but from here you can tweak the color to do lots of things. Change the hue = hue shift, change saturation = saturate/desaturate whole image, change the lightness = add/subtract lightness to whole image

white + difference = invert image, this also flips the hues to their opposites; combine with an HSL add layer above set to HSL 180/128/128 and you restore the hues while inverting the lightness.

solid color + hue = force entire image to one hue (reduce opacity to allow limited range of hues centered on layer's color)

solid color + color = force entire image to one hue and saturation (similar to above)

There are more combinations but these are the most important. And because it's a layer, these effects are "on top of" whatever changes are made to individual layers and gradients. It's not as versatile or precise as Photoshop's color controls, but when postwork isn't practical or desirable, it's a nice option to have.

--Damien

Mindy,

When you "render" you're asking UF to regenerate the entire image at high-res. The resulting image is automatically flattened as it's generated, unless you asked for a .PSD file, so rendering in UF doesn't require extreme amounts of memory even if you have a bazillion layers. However, UF still has to generate all the pixels for all the layers, so that's an awful lot of computation.

Remember that in UF, an image isn't just a collection of pixels; it's a collection of mathematical parameters, which are on-the-fly rendered on-screen as you work. It's like you're interactively building a set of instructions of how to make your image, and you can go back to any of the instructions and change them, and UF will rebuild your image from scratch. It is not like PS, where you proceed step-by-step, each modifying the previous step. In PS, when you save your image, you're saving the final result of all your pixel-pushing. You're not saving the step-by-step process(*). When you open parameters in UF, it's like you're going through the command history and reassembling your whole image, because that's UF's native operation. UF never manipulates pixel data directly; it's always manipulated via formula.

So no, you can't "flatten before you render" because that's something you do to pixels, not fractal formulas. UF just flattens-as-it-goes, whenever it's creating pixel data, for screen or final render.

(*) Yes, you can save your command history and use it to reconstruct your image from scratch, but that's not the primary workflow, and resizing your image doesn't automatically translate all your steps.

--Damien

The 64-bit processors won't really offer anything to UF, since the difference between 32-bit and 64-bit deals with integers, not the floating-point math UF uses. (Although theoretically it might improve the deepzooming support, if that were re-written for 64-bit, because deepzooming works by using lots of integers to fake a really big, precise number.)

Things that do matter are CPU speed, floating-point performance, multiple cores (which UF can use), and lots of RAM (if you're using flames). For Photoshop (Mindy's question) lots of RAM and fast disk almost matter more, because at the print sizes she's dealing with, those are the limiting factors.

--Damien

Jock,

Yes, that's about right--four pixels per second. The image is "Ailes", which has fBm done at each iteration, with a large number of iterations. It's the slowest fractal I've ever done, but none of the fourteen layers could be deleted without seriously affecting how it looked.

--Damien

Jock,

I don't recall what size Rick was rendering, but I typically do 4000x or 8000x (with appropriately-sized other dimension) for print-quality images. My longest was the 900 hours I referred to earlier in the thread, and that was for a 4000x3000. My current 8000x5667 has nine more hours to go, for a total of about thirty.

It's a good thing we're not trying to render fractal animations for film quality.

--Damien