In between working on other projects over the past month, I've been 
doing some experiments with image processing in POV.  My first 
installment is my latest experiment.

	While this is an interesting technique, I have yet to find any way to 
make it practical.  The biggest problem is one of memory: my computer 
has 2Gb of ram, but POV still crashes when parsing this effect at 
dimensions somewhere above 9.21875' by 5.25'.  This is due, no doubt, to 
the rather LARGE number of objects generated by my macro - at this size, 
there are roughly 148,680 individual objects.

	I plan to do some further experimentation to see whether or not I can 
make it more memory efficient, but I'm not holding my breath.

	The first image is a single color demonstration, this method is more 
efficient, memory-wise, but not as impressive as the full-color demo IMHO.

The second image is a full-color shot of the entire image, dimensions: 
9.21875' X 5.25'.  The third image is a cropped closeup render.

<A href="http://speedy.sdsmt.edu/~1305761/images/LED.jpg">Monochrome LED 
Display.</A>
<A href="http://speedy.sdsmt.edu/~1305761/images/LED3.jpg">Full Color 
LED Display.</A>
<A href="http://speedy.sdsmt.edu/~1305761/images/LEDCloseup.jpg">Full 
Color Closeup.</A>

Questions/Comments?

Regards,

ADB

Post a reply to this message

Anthony D. Baye wrote:

> The second image is a full-color shot of the entire image, dimensions:
> 9.21875' X 5.25'.  The third image is a cropped closeup render.
> 
> <A href="http://speedy.sdsmt.edu/~1305761/images/LED.jpg">Monochrome LED
> Display.</A>
> <A href="http://speedy.sdsmt.edu/~1305761/images/LED3.jpg">Full Color
> LED Display.</A>
> <A href="http://speedy.sdsmt.edu/~1305761/images/LEDCloseup.jpg">Full
> Color Closeup.</A>
> 
> Questions/Comments?
> 
> Regards,
> 
> ADB

Neat :)

I have done something similar some time ago and didn't run into mem
problems. What I did was group all leds of the same color into unions. Yes,
I know, it will turn into a very large number of unions, but that's pov's
problem :)

Hth

-- 
Ger

Post a reply to this message

"Anthony D. Baye" <ant### [at] goldsdsmtedu> wrote in message 
news:44c6909a@news.povray.org...
> I plan to do some further experimentation to see whether or not I can make 
> it more memory efficient, but I'm not holding my breath.

Wow, it looks nice.  This would look great as an animation zooming into the 
picture.

I did a brief experiment a while ago with the same idea, but mine was to be 
a 'hologram' projection.  I put a spotlight about every 10 pixels or so, but 
used a transparent block with the actual image mapped on it, with a grid 
'overlay' to shape the pixels.  I also tried a spherical ball with the right 
color, similar to your idea, but decided it looked too grainy.

Are you using a Union or difference?

So mine wouldn't show NEARLY your detail, but it did have the interesting 
effect of 'projecting' a blurred image into the viewers.  As near as I 
remember memory wasn't bad, but of course there were a lot of spotlights, 
which could have other bad effects.  I can't remember if I tried radiosity 
or not.

I also didn't post it anywhere ...

         == John ==

Post a reply to this message

Nice. I personally the first one is the best, mostly because it looks more
connected than the second one, and also because I'm a sucker for
monochrome.

As for memory usage, the only tip I can give would be to drop the CSGs and
use cylinders (or some other such object), unless the CSGs are necessary
for what you have planned.

By the way, Castle in the Sky, right?

Post a reply to this message

Anthony D. Baye nous apporta ses lumieres en ce 25/07/2006 17:43:
>     In between working on other projects over the past month, I've been 
> doing some experiments with image processing in POV.  My first 
> installment is my latest experiment.
> 
>     While this is an interesting technique, I have yet to find any way 
> to make it practical.  The biggest problem is one of memory: my computer 
> has 2Gb of ram, but POV still crashes when parsing this effect at 
> dimensions somewhere above 9.21875' by 5.25'.  This is due, no doubt, to 
> the rather LARGE number of objects generated by my macro - at this size, 
> there are roughly 148,680 individual objects.
> 
>     I plan to do some further experimentation to see whether or not I 
> can make it more memory efficient, but I'm not holding my breath.
> 
>     The first image is a single color demonstration, this method is more 
> efficient, memory-wise, but not as impressive as the full-color demo IMHO.
> 
> The second image is a full-color shot of the entire image, dimensions: 
> 9.21875' X 5.25'.  The third image is a cropped closeup render.
> 
> <A href="http://speedy.sdsmt.edu/~1305761/images/LED.jpg">Monochrome LED 
> Display.</A>
> <A href="http://speedy.sdsmt.edu/~1305761/images/LED3.jpg">Full Color 
> LED Display.</A>
> <A href="http://speedy.sdsmt.edu/~1305761/images/LEDCloseup.jpg">Full 
> Color Closeup.</A>
> 
> Questions/Comments?
> 
> Regards,
> 
> ADB
Nice effect.
Suggestions:
1 - Use single elements elements, such as cylinders or stretched spheres, as 
much as possible, maybe using normals to fake any desired rounding. Thinking of 
a leopard pattern for the normal.
2 - Place all red in an union. Do the same for green and blue. If you use an 
image for the pattern, use it with .red, .green and .blue and apply using 
image_map to the whole union.
3 - NEVER apply a texture to individual element.

Textures applied to a 10000 objects union are defined ONCE. If you apply the 
same texture to 10000 objects, you get 10000 instances of the texture. That 
takes a lot more memory.

-- 
Alain
-------------------------------------------------
BE ALERT!!!!  (The world needs more lerts ...)

Post a reply to this message

"Anthony D. Baye" <ant### [at] goldsdsmtedu> wrote:
> In between working on other projects over the past month, I've been
> doing some experiments with image processing in POV.  My first
> installment is my latest experiment.
>
>  While this is an interesting technique, I have yet to find any way to
> make it practical.  The biggest problem is one of memory: my computer
> has 2Gb of ram, but POV still crashes when parsing this effect at
> dimensions somewhere above 9.21875' by 5.25'.  This is due, no doubt, to
> the rather LARGE number of objects generated by my macro - at this size,
> there are roughly 148,680 individual objects.

What is it?  Looks like a 295x168 TV up very close.  Not sure why your
dimensions are a factor of 32.  Not quite sure what this object is that you
created.  But 295 x 168 x 3 = 148,680 objects.

Looking again, I'm guessing you read each pixel of a photo and divided them
up into R, G, B components, created a cell with 3 atoms in it, each having
an R, G, B atom, based on the pixel values of the photo....?

If that's it, then would it be "cheaper" to first split your photo into 3
gray photos and do the similar process?  (Cheaper on memory?)

Post a reply to this message

"Anthony D. Baye" <ant### [at] goldsdsmtedu> wrote:

>  While this is an interesting technique, I have yet to find any way to
> make it practical.  The biggest problem is one of memory: my computer
> has 2Gb of ram, but POV still crashes when parsing this effect at
> dimensions somewhere above 9.21875' by 5.25'.  This is due, no doubt, to
> the rather LARGE number of objects generated by my macro - at this size,
> there are roughly 148,680 individual objects.

.... On second thought, if it's possible in POV-Ray (which I'm too novice to
know for sure), try processing only 1 row at a time, instead of the full
image.

You mentioned "macro".... so would it be possible to call your macro 168
times, one for each row?

Post a reply to this message

Anthony D. Baye wrote:
>     In between working on other projects over the past month, I've been 
> doing some experiments with image processing in POV.  My first 
> installment is my latest experiment.
> 
>     While this is an interesting technique, I have yet to find any way 
> to make it practical.  The biggest problem is one of memory: my computer 
> has 2Gb of ram, but POV still crashes when parsing this effect at 
> dimensions somewhere above 9.21875' by 5.25'.  This is due, no doubt, to 
> the rather LARGE number of objects generated by my macro - at this size, 
> there are roughly 148,680 individual objects.
> 
>     I plan to do some further experimentation to see whether or not I 
> can make it more memory efficient, but I'm not holding my breath.
> 
>     The first image is a single color demonstration, this method is more 
> efficient, memory-wise, but not as impressive as the full-color demo IMHO.
> 
> The second image is a full-color shot of the entire image, dimensions: 
> 9.21875' X 5.25'.  The third image is a cropped closeup render.
> 
> <A href="http://speedy.sdsmt.edu/~1305761/images/LED.jpg">Monochrome LED 
> Display.</A>
> <A href="http://speedy.sdsmt.edu/~1305761/images/LED3.jpg">Full Color 
> LED Display.</A>
> <A href="http://speedy.sdsmt.edu/~1305761/images/LEDCloseup.jpg">Full 
> Color Closeup.</A>
> 
> Questions/Comments?
> 
> Regards,
> 
> ADB
Yes, It's Castle In the Sky.

Alright, here's the basic layout.

I have three macros

      LED(dT, dC, dL, dP) // This macro defines a single Light emitting 
diode of a given type (the first parameter is largely vestigial, I just 
haven't taken it out yet.) The second parameter controls the color, the 
third is the Hue, and the fourth controls position via a transform block.

      ColorBlock(rV, gV, bV, pos) // defines a 3/8" square brick 
containing three LEDs in a molded block. (this is one place where 
refinement might be possible.) The macro takes in hue values for red, 
green and blue values. The fourth is a transform block.

      Display(dSize, bSize, dImage) // The first two parameters take 
<u,v> pairs as the height and width of the display, and the height and 
width of the individual color blocks.  The second parameter is obsolete, 
it was simply a carry-over from one of my other macros that I 
reverse-engineered.  The third parameter is the source image file in 
JPEG format.

      Display(...) reads the image into an image map, which is then 
scaled to the display size.  Calculations are performed to determine how 
many times the individual blocks will fit into the display these are 
defined as (a) and (b).

      Two while() loops are initiated, (b) on the outside, (a) on the 
inside. Loop (a) handles horizontal translation while loop (b) handles 
virtical translation. The image is laid out row by row, starting at the 
bottom.
      As each block is placed, the macro reads the image_map for red, 
green and blue values at the same location (If you have'nt guessed, yet, 
this uses the eval_pigment() macro.) These values are passed to the 
ColorBlock(...) macro along with a position vector.
     The inner loop increments until an entire row is complete, then the 
outer loop increments.

      In the case of the monochrome display, I simply averaged the three 
color values and passed the result straight to the LED(...) macro along 
with a standard color for the display.

      There are probably quite a few ways to simplify my model.  One of 
my current ideas is replacing my LED CSG model with an Isosurface 
created from a cylindrical pigment.  I'd have to try it to know if it 
would work, though.
      I don't know about texturing the pieces as a whole, I'd have to 
re-think my entire model.  I know that it doesn't transform well once 
complete, so I'd considered writing a sub process that would allow it to 
be built around a given point, but I'll see.

Thanks for your input.

Regards,

ADB

Post a reply to this message