|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I posted a little blurb about a utility (TGAMosaic) I have been toying
with on and off for some time to povray.binaries.utilities. It's along
the lines of tgadot, although I wasn't aware of tgadot when I first
started working on it. It takes a TGA image and creates a POV scene file
where the pixels are represented by a variety of objects. In this case
I'm using spheres. It differs from tgadot in several ways, most
noticeably in that it doesn't represent all of the image pixels, which
can get to be a lot of objects pretty quickly (640x480=307,200
objects!). It also can scale the pixel objects according to original
pixel color and contrast, and allows for animation to blow the picture
to smithereens. Any comments are welcome, and I will try to post some
better results from it, as these are not very indicative of what it can
do
--
--------------------
"There are three men in a boat with four cigarettes but no matches.
How do they smoke??"
-The Riddler
Andrew Woodfin
UNC Charlotte Center for Precision Metrology
adw### [at] unccedu
--------------------
Post a reply to this message
Attachments:
Download 'tanks.jpg' (103 KB)
Preview of image 'tanks.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Andrew Woodfin wrote:
>
> I posted a little blurb about a utility (TGAMosaic) I have been toying
> with on and off for some time to povray.binaries.utilities. It's along
> the lines of tgadot, although I wasn't aware of tgadot when I first
> started working on it. It takes a TGA image and creates a POV scene file
> where the pixels are represented by a variety of objects. In this case
> I'm using spheres. It differs from tgadot in several ways, most
> noticeably in that it doesn't represent all of the image pixels, which
> can get to be a lot of objects pretty quickly (640x480=307,200
> objects!). It also can scale the pixel objects according to original
> pixel color and contrast, and allows for animation to blow the picture
> to smithereens. Any comments are welcome, and I will try to post some
> better results from it, as these are not very indicative of what it can
> do
> Andrew Woodfin
Here are a couple of images I produced last night with this useful
little utiliy. The first image used the non linear object scaling and
the second used the uniform scaling option. I like the appearence of
depth obtained as seen in the first image, but prefer the compared
color accuracy form the original to the pov version, better as it
appears in the second image.
Regards,
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
Attachments:
Download 'cat.jpg' (89 KB)
Download 'cat1a.jpg' (67 KB)
Preview of image 'cat.jpg'
Preview of image 'cat1a.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Andrew Woodfin wrote:
> ...pixel objects according to original
> pixel color and contrast, and allows for animation to blow the picture
> to smithereens.
> Andrew Woodfin
I spent quite a bit of time last tonight trying to figure out what
this guy could possible have been thinking whan he added a clock
modifier to every single objects translation statement, Not just
for one direction but for all three three at one time. How was I
to guess that it was the long awaited "Blow it to Smithereens"
option ? I had thought that maybe there was a bug in the std.out
directive until I found that brief mention of the feature above.
While I agree that it is a novel idea I suggest a command line
option for it's inclusion. Edited out through search and relplace
yielded a file size reduction of 70k for a 640x480 image -> sphere
conversion I tried last night. A similar file output size and memory
enhancement for the cylinder output option could be implemented
as well. Currently if you specify the single color option the
program is writing a seperate texture statement for each cylinder
in the file.
This adds little to no flexibility to the scene file, but the
overhead is high for formatting the scene file in this way. It
would be better to wrap all of the cylinders in a simple union and
and treat them with one global texture statement. When applied on
a object by object basis as is the method now, the program must
calculate the seperate texture, scale it, rotate it, translate it,
and then adds a memory pointer for the texture on each and every
object in the scene. This adds another 80k in physical file size
and nearly doubles the memory requirements for the scene file.
Suggestions for other possible modifications or changes in
user definable options are:
1.) user declare object spacing - center line to center line.
Currently the program allows for % of pixels sampled and
the object size is based loosely on this. Even where the
provision for the objects size has been made it does not
help dictate object placement. If too small an object size
is used, the spacing between them becomes to great, and the
pattern is effected in a negative way.
2.) Option to apply the original image as an image map overay
to the ojects generated as opposed to individualy pigmented
objects. I am not suggesting removal of the current process
but I feel there are times where it would be nice to have
the alternative available. Since the program already knows
the boundries of the entire object it is easier for it
to scale and translate an image map into place than it is
for the user to try to calculate themselves.
3.) Related to the last would be an option to have the program
wrap all object in a union, normalize it's position in
relation to the origin, and then scale it down to a unit
sized object. It is difficult to know how large and where
it is exactly right now and attempts to move and scale it
results in time consuming operations to position and scale
it elsewhere in the scene.
4.) A general observation you may act upon or ignore at your own
discretion. Programs that produce a large number of objects
for Pov, and this part I still don't understand, will invariably
use formatting of the Pov script that comsumes a very large
chunk of real estate. For example you have in your translate
statements:
<2.24 +clock*1.402, 10.2 +clock*3.3, -3.32 +clock*12.343>
That is a lot of file space for something that could be handled
differently and produce the same functionality. If for example
you declared an abreviation for the clock at the top of the file
you could loose up to 12 characters per line.
Example:
#declare T = clock;
<2.24 +T*1.402, 10.2 +T*3.3, -3.32 +T*12.343>
If yuu removed the double spaces after each comma, and before
the + sign that is an additional 10 character spaces removed
from the file. Example:
<2.24+T*1.402,10.2+T*3.3,-3.32 +T*12.343>
While these changes seem petty on a line by line basis they
add up in a big hurry when your object numbers in excess of
a couple of thousand. I also know that it really grates on
the nerves of programmer types to vary from the very rigid
language structures they use in the code but lets face it,
nobody is going to go through a 1 meg file generated by
your program and try to read it on a line by line basis.
All they are likely ever to see is the first twenty and last
twenty lines and rest are obscurred for eternity. I did a
little creative editing on one of the files I tested last
night to see exacstly how far I could reduce the file size
without changing the functionality of the content.
Initial file size 1,144,240
Removed spaces between comma seperators 1,068,741 -> - 75,499
Removed word color from the entire file 1,100,261 -> -63,480
Finished removing every uneeded space 833,861 -> -171,400
Total savings in file size after edit = 310,379
As you can see that works out to a file size savings of nearly
one third of the original. With a few other replacement tricks
I probably could have got that down to about 700k but I feel
I have illustrated my point well enough with my examples.
That is an impressive amount and the consequences of files with
that much dead space simply imply the amount of hard drive space
each one consumes. Pov doesn't really care one way or another but
I do.
Anyway I thought I would take the time to offer my observations
and suggestions and I hope you find them useful to you.
Thank you,
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have to cut in here:
<<<<<< snip ideas and comments>>>>
> 3.) Related to the last would be an option to have the program
> wrap all object in a union, normalize it's position in
> relation to the origin, and then scale it down to a unit
> sized object. It is difficult to know how large and where
> it is exactly right now and attempts to move and scale it
> results in time consuming operations to position and scale
> it elsewhere in the scene.
Hmm, not a one unit size object, that would cause a too big data-loss in most
cases(the epsilon values) but instead a 10 or 100 unit sized object. This isn't
very meaningful in smaller images, but when it comes to larger ones(more data)
it is important or there may be visible changes in the image.
--
//Spider
[ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
"Marian"
By: "Sisters Of Mercy"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Spider wrote:
>
> I have to cut in here:
> <<<<<< snip ideas and comments>>>>
> > 3.) Related to the last would be an option to have the program
> > wrap all object in a union, normalize it's position in
> > relation to the origin, and then scale it down to a unit
> > sized object. It is difficult to know how large and where
> > it is exactly right now and attempts to move and scale it
> > results in time consuming operations to position and scale
> > it elsewhere in the scene.
> Hmm, not a one unit size object, that would cause a too big data-loss in most
> cases(the epsilon values) but instead a 10 or 100 unit sized object. This isn't
> very meaningful in smaller images, but when it comes to larger ones(more data)
> it is important or there may be visible changes in the image.
>
> --
> //Spider
I do not suggest that you scale it automaticaly to 1x1x1 rather
my intention is an object that would not exceed a 1 unit boundry
in any it's the scalable directions i.e.
The object is scaled at:
scale<8,4,0.5>
A uniform rescale of:
scale 0.125
would fit it inside a one unit square boundry. There would be no data
loss as a result of this. I am not asking to rescale the image or any
single object rather put them all in one union then scale the whole
thing as a single entity.
I should have been more clear on that. Sorry.
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Many thanks, Ken. I have yet to take any steps to reduce the output file
size, but I definitely see your point. As for the other suggestions, I'll
see what happens when the mood strikes.
Andy
Ken wrote:
> Andrew Woodfin wrote:
>
> > ...pixel objects according to original
> > pixel color and contrast, and allows for animation to blow the picture
> > to smithereens.
> > Andrew Woodfin
>
> I spent quite a bit of time last tonight trying to ..
>
> Anyway I thought I would take the time to offer my observations
> and suggestions and I hope you find them useful to you.
>
> Thank you,
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net
--
--------------------
"There are three men in a boat with four cigarettes but no matches.
How do they smoke??"
-The Riddler
Andrew Woodfin
UNC Charlotte Center for Precision Metrology
adw### [at] unccedu | http://www.coe.uncc.edu/~adwoodfi
--------------------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|