 |
Author |
Topic: attractors... sparks... blurry smoke (Read 3064 times) |
|
JohnG
|
Re: attractors... sparks... blurry smoke
« Reply #15 on: May 26th, 2004, 4:50pm » |
|
Heh, you have no idea how tempted I've been on many occasions to take advantage of a new server here.
I think I could just about live with 8GB of ram to render things into, and 4 processors.
Everyone else using the machine might not agree with me though, unfortunately.
8192*8192 images are possible with 512MB (256MB of image at 8192*8192*32BPP, you normall yneed double, as the file save functions tend to end up with a full copy of the original image whilst encoding with many libraries)
It's not supreme print quality, but things don't tend to look too bad at 150DPI on a wall, so that'd give you 56"*56".. or 28"*28" if you really want 300DPI.
However I would suggest setting up a new BGraphics for the full size image instead of just doing size(big,big), as your OS probably doesn't like trying to draw 5 feet off the side of the screen 
|
|
|
|
|
amoeba
|
Re: attractors... sparks... blurry smoke
« Reply #16 on: May 26th, 2004, 5:41pm » |
|
on May 26th, 2004, 4:35pm, TomC wrote:| Of course, the yardstick is now Mr Tarbell's 10200x6600 images at 2800dpi. |
|
Photoshop can make really big images when rasterising. It just takes forever. Good luck!
|
marius watz // amoeba
http://processing.unlekker.net/
|
|
|
Markavian
|
Re: attractors... sparks... blurry smoke
« Reply #17 on: May 30th, 2004, 2:03am » |
|
Oh, you've all taken an interest in printing them?
Me to!
Infact, I came on to post that I'd just finished work on altering TomC's code to make my own processing 'renderer'.
I'll post the code later if anyone is interested, but for now I'll tell you I added the following features:
Default size value : (e.g. 600, 400)
Scale value : scales default size and the image
(Scale value 5 = 3000x2000 render, plenty big for A4 prints)
Contrast : I found you get better smoother images with transparency of 1, but faster visulation times with more opaque values, so contrast helps speed up visulations.
Num cycles : So you know how many points its plotted (particles * cycles)
Cycle Limit : So you can stop the render before it over exposes... and so it Saves to File:
Save to file (F key) : So you can save the image at any time before the cycle limit.
- Copy area of image to BImage before:
- Text added to page : num cyclces, num particles, num attractors, acceleration, contrast.
- Text covered over again using BImage.
Fixed attractor positions: 0 < x < 1.0, 0 < y < 1.0
In my version of the code I also attempted to prevent over exposure (big fat black lines), by adding a thin veil of red along side overexposed sections... sort of shifting the over exprosure into something a bit more colourful.
Right now I'm rendering a 3000x2000 image on my laptop, its got 172 Mb of Ram and occasionally throws Java.lang outOfmemory errors, but its okay once it gets going.
Heres one I made earlier. Thx for the code TomC. I like your more then Jared's because its so much... simpler.
http://mkv25.net/showcase/screens/screenshot_20.png
I intend to make a little folder full of renders printed out onto paper, just 'cause they're great to look at.
The only post processing needed so far was deleting the near-white sections of the image (oh no!) most printers can't handle dots _that_ small and just paint a thin splattering over the paper, which looks bad.
Idealy, the render would be in black and white only, and a pixel would be printed at the same resolution as the printer is capable of, then it'd be a perfect plot...
Anyway, this is sorta fun.
Kind Regards,
- Markavian
|
|
|
|
|
TomC
|
Re: attractors... sparks... blurry smoke
« Reply #18 on: May 30th, 2004, 3:21am » |
|
on May 30th, 2004, 2:03am, Markavian wrote:
I'll post the code later if anyone is interested
|
|
Yes please... it's only fair 
on May 30th, 2004, 2:03am, Markavian wrote:
Cool! Not sure about the red though...
Another way to avoid the "over-exposure" is to keep a separate buffer of exposure counts. Rendering the buffer instead can give a much more subtle effect - because it uses the full 32-bit range. It needs a bit of experimentation to boost the mid range, but the results are worth it. Here's what I have so far:
http://www.tom-carden.co.uk/p5/attractors_work_in_progress.jpg
http://www.tom-carden.co.uk/p5/attractors_work_in_progress2.jpg
Interactive version pending.
|
| « Last Edit: May 30th, 2004, 3:34am by TomC » |
|
|
|
|
Markavian
|
Re: attractors... sparks... blurry smoke
« Reply #19 on: May 30th, 2004, 3:57am » |
|
Good work adjusting the contrast! Far more lines are visible.
Need to clean up my code before I post ::embarrased::, and its 3am right now... I was adding a 'zoom' function too that let me add some white space around the image, but I ended up screwing up your nicely balanced acceleration and damping variables.
Like you said, moving everything to a 'virtual' buffer should work much better, rendering to screen becomes the last thing to worry about, and will be easier to perfect if the pattern information is stored properly / universally accesible. i.e.. without zoom/scale/crop/contrast information
(which is basically the direction I'm taking your code at the moment)
Regards,
- Markavian
|
|
|
|
|
Markavian
|
Re: Render Setup
« Reply #21 on: May 31st, 2004, 12:29pm » |
|
Hi TomC (and other readers?),
Not so keen on your colours at the moment. They still look brilliant, but its kinda colour diareah. Its better if you stick to a palette of colours rather then throwing all of the hue channels at the image. That said, just keep tweaking it =) I'm gonna start looking at your code soon to solve my 'contrast' problems.
Anyhow, heres my code (see below), I've named it renderSetup... credit goes to the important 10 lines of code that are yours...
... if you look and see what I've done, there are variables that let you set the scale and zoom of the image. The rest of my code is for writing text to the image, and saving the image to a file.
Note how I've rewrote the scaling of the particle generation to be within a generic range. I also had to fix the Attractor positions, which is a pain because it spoils the randomness factor. Originally I was using 'noise()' as a random offset, but apparently the noise default is randomised each time you use it. So noise(10) on one run isn't the same as noise(10) on the next run... and that defied the point of having fixed attractors.
You will need to create a font before you can use the saving part of the script, I used Arial_Narrow, at size 72... I've not tested other font styles yet... but it provides a nice summary to go with the image.
cycleLimit allows you to automatically save an image after a period of time.
At a future stage, I'd like to draw a mini-map showing the positions of the Attractors, and stick it in the corner of the image or something.
Oh, the other thing is: pressing the mouse pauses/plays the generation, which is quite handy.
http://mkv25.net/showcase/screens/renderSetup_a0.pde
Regards,
- Markavian
|
|
|
|
|
TomC
|
Re: Render Setup
« Reply #22 on: May 31st, 2004, 1:10pm » |
|
on May 31st, 2004, 12:29pm, Markavian wrote:
Not so keen on your colours at the moment. They still look brilliant, but its kinda colour diareah.
|
|
Charming! 
on May 31st, 2004, 12:29pm, Markavian wrote:
Its better if you stick to a palette of colours rather then throwing all of the hue channels at the image. That said, just keep tweaking it =) I'm gonna start looking at your code soon to solve my 'contrast' problems.
|
|
As always, it's a work in progress. I'm actually looking at changing the palette at the moment. Need one that's seamless for the current technique though, hence just using the whole spectrum until I figure out a nice way to use limited hues.
on May 31st, 2004, 12:29pm, Markavian wrote:
Anyhow, heres my code (see below), I've named it renderSetup... credit goes to the important 10 lines of code that are yours...
|
|
Credit would be nice in the source actually. I'm not demanding this, but it's not much to ask. I'm actually going through all my code at the moment to retrofit it with a Creative Commons license (a la Toxi) which is probably going to be the attribution/non-commercial/share-alike version.
on May 31st, 2004, 12:29pm, Markavian wrote:
Top stuff. Thanks
|
|
|
|
|
tobt
|
Re: attractors... sparks... blurry smoke
« Reply #23 on: Jun 24th, 2004, 5:55pm » |
|
on May 26th, 2004, 4:50pm, JohnG wrote:
8192*8192 images are possible with 512MB (256MB of image at 8192*8192*32BPP, you normall yneed double, as the file save functions tend to end up with a full copy of the original image whilst encoding with many libraries)
|
|
Hello,
the biggest image, I could create is about 2000 x 2400 Pixel. This is just a 30 x 40 cm image at 150 dpi. save() made a 14 MB file. Too small for a poster and of course I want to do a poster.
When increas the resolution, I get a java.long.OutOfMemoryError.
Can anybody help me I use Mac OS X, Processing 68 and 1.5 GB RAM. Thanks.
|
| « Last Edit: Jun 24th, 2004, 5:56pm by tobt » |
|
|
|
|
JohnG
|
Re: attractors... sparks... blurry smoke
« Reply #24 on: Jun 24th, 2004, 8:03pm » |
|
On windows the run.bat has this line in it:
start javaw -ms128m -mx128m PdeBase
the 128 is how much memory processing can use.
I assume the Mac version has some similar startup file, with similar limits. Change those numbers and you should be able to have bigger images.
|
|
|
|
|
Koenie
 
|
Re: attractors... sparks... blurry smoke
« Reply #25 on: Jun 24th, 2004, 10:12pm » |
|
I don't know if you used this kinda thing before, but I've also tried to render big resolution images. Here are the steps and a bit of example code.
1. Make a big BImage: Code:| BImage img = new BImage(2000, 2000); |
|
2. Fill the BImage instead of the screen: Code:
3. Save the BImage: Code:| img.save("big_image.tif"); |
|
In this case, you don't even have to draw to the screen at all (you could just use a 100 x 100 window, for example), but you can still get really big images.
Just my two cents,
Koenie
|
http://koeniedesign.com
|
|
|
tobt
|
Re: attractors... sparks... blurry smoke
« Reply #26 on: Jul 1st, 2004, 11:35pm » |
|
on Jun 24th, 2004, 10:12pm, Koenie wrote:
1. Make a big BImage: Code:| BImage img = new BImage(2000, 2000); |
|
2. Fill the BImage instead of the screen: Code:
3. Save the BImage: Code:| img.save("big_image.tif"); |
|
|
|
Hi,
if I can understand this way, it's only possible to draw by setting pixel for pixel. Right
But I have a script, which uses bezierVertex(x,y) ... so I can't do this way. (e.g. It's not possible to say: "img.line(x,y))" No
Thanks for help, tobt
|
|
|
|
|
toxi_
Guest
|
Re: attractors... sparks... blurry smoke
« Reply #27 on: Jul 2nd, 2004, 11:40am » |
|
instead of using an BImage offscreen buffer, you can also create a new BGraphics instance and so have access to all the usual drawing functionality and don't have to do stuff on a per-pixel basis:
Code:BGraphics img = new BGraphics(2000, 2000);
img.background(255);
img.stroke(0,50);
int halfWidth=img.width/2;
for(int i=0; i<img.width; i+=2) {
img.line(
halfWidth-halfWidth*cos(i*0.01),0,
halfWidth+halfWidth*sin(i*0.01),img.height
);
}
img.save("big_image.tif"); |
|
just make sure to always add the object reference infront of the drawing commands if you are targetting the offscreen image.
note: lines might suffer of loss of precision in very large resolution images. the current line code is not intended for hi-res works, but we might change that now that there's increased interest in this direction.
|
|
|
|
|
tobt
|
Re: attractors... sparks... blurry smoke
« Reply #28 on: Jul 8th, 2004, 10:40pm » |
|
on Jul 2nd, 2004, 11:40am, toxi_ wrote:instead of using an BImage offscreen buffer, you can also create a new BGraphics instance and so have access to all the usual drawing functionality and don't have to do stuff on a per-pixel basis:
|
|
But here I have the same limitations. Files bigger than 2000x2400 do not work. (I wrote aboute the problem a few days before in this thread.) The idea sounds good but I want to make posters ...
|
|
|
|
|
Markavian
|
Render Setup
« Reply #29 on: Aug 11th, 2004, 1:52pm » |
|
I think the best way to progress with high resolution image production is to produce a script that renders areas of an image, that you can stitch together at a later point.
You can create a useful set of variables to allow you to do this such as a 'camera offset' and 'zoom'/'scaling'. It should then be possible to write these variables into your script and render images more precisely.
I've already gone a long way with TomC's script, altho I'm not so keen on the new generation code:
http://mkv25.net/applets/renderSetup_b1/renderSetup_b1.pde
Regards,
- Markavian
|
|
|
|
|
|
