I everybody, I have a question: Its posible to export an image of a composition in jpg or tiff or pdf? if it posible i don't know how... help!
thnkx!
marcos
There's a 'save screenshot' option in the viewer menu. Otherwise, there's a patch to save an image, but I remember it being an example plugin so you'd have to find it in the developer examples and compile it.
the movie exporter patch found in the dev. examples folder (needs to be compiled), can save only Quicktime Movies out of the box (even though the internal compressor is set to TIFF for instance).
A real Image exporter would be handy....
I'm sure it's trivial to add logic to test if the plugin is running on a PPC or Intel machine and switch the pixel format accordingly. I wouldn't know how to do that though. Anyone happen to know how you'd test for processor-type in a QC plugin using ObjectiveC/Cocoa?
Compositions are (and always should be) platform agnostic (at least for endian issues; video cards, on the other hand, are justified) -- the correct solution to this would be to make the plugin do the endian detection itself.
Further, endianess shouldn't involve any extra executing code, since it's a compile-time constant. As such, you'll typically add a chunk of code that looks like this:
the pound signs are for the compiler, not the program. There is no variable called BIG_ENDIAN, but there's a "compiler variable" (basically an environment variable) so when the compiler builds the code, it'll do those conditional checks, and build the program based on what it evaluates.
Because of this, you can't really use it like a variable as you have (technically you can, but that's not going to give you the correct behaviour).
it should look exactly like the example above (#ifdef, #else, #endif), in the objective-C code.
[edit: in the source code, around line 75 of ImageWriterPlugin.m, you'll have something like this:
I somehow assumed you'd written it in some obscure 'other' language, and I was attempting to translate it into what looked like ObjC (from the evidence of the rest of the code). I really should leave the programming to the programmers...
Well, at least until my Cocoa book arrives.
Actually, I'm still a bit confused here, I'm afraid.
I thought XCode compiled the plugin when you hit Build. In which case, wouldn't it just compile the code in one way if you happened to be building the plugin on an Intel machine, and in another if you were on a PPC Mac (so you'd effectively still get an endian-specific plugin, albeit one that worked on your current system)?
Sorry if it's a stoopid question; I've only ever really worked with interpreted code, so I'm a bit vague on compiled language and their terminology.
It's a bit complicated actually. Your mind is in the right place though.
in xcode, if you right click the project, and go into info, you can see some properties, like this:
Note the two architectures, ppc and i386. When both of those are enabled, the compiler will actually compile the source twice, once for each architecture. It'll then glue them together into a "fat binary" (universal binary), and when you run it on your mac, it's smart enough to pick the correct one.
The magic then happens like this: For each architecture (there are actually 4 for Leopard, ppc, ppc64, i385, and x86_64. maybe arm too if you count iPhone/iPod touch stuff I guess), the compiler will have different environment variables that describe the environment. Big Endian is only set on big-endian CPUs, otherwise it's left unset. (There are other variables too, but I can't think of them off the top of my head). This way, the compiler builds the "right" version. An added side effect is that the two binaries are actually a little bit different in what they do. This can be abused -- for example, you could make one whole program, and have it all in an intel-detect block, and then an entirely separate program in a ppc block, so it'd look like one app to the user, but it'd be totally different depending on whether or not they were on ppc or intel. I've not seen anyone do this, but it's entirely possible without any dark hackery.
I'd forgotten about fat binaries.
Sooo... it's going to compile both, anyway, and you're just telling it to specifically make the pixelFormat different according to endian-ness.
As we are in writing image to disk land, is it not time to add some little robust option to the image writer patch ?
PNG work well for still capture...but is it the best format to write Image sequence at 25/30 FPS on disk ?
what is the best format to do this ?
We need a 32 bits format (rgba)
and no compression.
perhaps 16 or 32bits per channel....
PNG,TGA ,TIFF, PSD, DPX, EXR ?
I'm considering using Image Writer to store 'preset images' for my 3D mesh-creator. The idea is, you feed video through it, until you get a mesh shape you like (the video deforms the mesh in realtime), then you can save the deformation image as a preset.
In engineering, "best" is usually too vague to mean anything. I'm guessing you mean "best format to do this" as in "fastest"?
In that case, uncompressed png and uncompressed tga have the least overhead (I used to write tga readers and writers just to practice programming when I was in highschool), so that should go quickly. That said, the images can be huge, and that can cause a bottleneck if your disk is slow. PNG with a little compression might be fast enough to work, and save enough space to not bog down the harddrive. It all depends on image size and content though.
psd and exr have way too much overhead for this, and I know nothing about dpx.
Yes Christopher, sorry for this non-engineering language...
I was talking about a good ratio in term of recording speed and quality.The challenge is not the same with a G5 connected with fiber channel to an xserve raid (or with a sata caldigit S2VRHD, to speak of what i know ) and a powerbook G3 with a filled disk...:)
There are a lot of design with gradient in QC so 256 greys levels/per channel is sometimes not enough for mastering screenshots or sequences. in video production we work with 10 bits for broadcast (1024 grey levels), SDI video cards are generally 10 bits.
For 3D rendering, Tiff 16 bits is cool because it preserve gradients, but this is 4Mo/image in SD (100 Mo/s), so you need a raid for "raisonable interactive compositing work". (I don't talk about 32 bits per channels because I never worked with such a color depth...:)
So my question is : what is the fastest format to be real time recorded on disk and that consume the less CPU ?
and with loseless quality
PNG, TGA or TIFF ?
I will do some test with after effetcs (rendering animated fractal noise), and i'llcome back with consistents infos.
So i have done rendering tests with after effects and Apple motion (because the time after effects take for recording PNG afraid me ...)
(50 Go of space free on disk after the test)
After effects :
1500 frames rendering with a color noise still image (1280x720)
Quicktime animation RGBA 3mn15s
Quictime none RGBA 3mn30s
TIFF RGBA 4mn33s
PNG RGBA 19mn15s (yes i'am afraid !)
TGA RGBA 3min48s
JPEG RGB 4min2s
Apple Motion :
250 frame rendering with a colornoise still image (1280X720)
Quictime Animation RGBA 40s
Quictime none RGBA 23s
TIFF RGBA 63s
PNG RGBA 174s (yes it is true ...very slow !)
TGA RGBA 23s
JPEG RGB 39s
Open EXR 250s
PSD RGBA 26s
With Apple : TGA and quicktime none or PSD for speed recording !
is png compression enabled? That might be causing the massive overhead (png compression is lossless, but really lousy for most image material -- LZW isn't well-suited for photo-like images). If not, I guess it's a horribly slow library, or apple's implementation is bad. shrugs can't really tell without more testing.
Looks like PSD is much more light-weight than I thought, about the same as TGA. I guess either of those would be good choices.
EXR also has a few different modes of operation, including lossy and lossless, as well as uncompressed. uncompressed EXR should be fairly snappy, but very very large...
I have no idea what those options mean/what they'll do. I imagine they have to do with sampling or something (adaptive is a method of antialiasing, for example), but I don't know how that translates into compression. Maybe do some tests with different options, and check files sizes as well as times?
There's a 'save screenshot' option in the viewer menu. Otherwise, there's a patch to save an image, but I remember it being an example plugin so you'd have to find it in the developer examples and compile it.
Developer/Examples/Quartz Composer/Applications/ ther's an app named "Poster" look at this I hope is useful...
the movie exporter patch found in the dev. examples folder (needs to be compiled), can save only Quicktime Movies out of the box (even though the internal compressor is set to TIFF for instance). A real Image exporter would be handy....
The Image Writer plugin in /Developer/Examples/Quartz Composer/Plugins is PPC-only, unfortunately.
Happily, I've managed to modify it so it works on Intel machines (it was just a slight change to a single keyword in the code).
I've uploaded versions of the plugin for PPC and Intel machines here: http://158.223.20.36/temp/ImageWriter_PPC-INTEL.zip
alx
Quartz Composer Blog: http://machinesdontcare.wordpress.com
Music Site: http://www.toneburst.net
I should add that it saves-out images in PNG format (but these can easily be converted into another format afterwards).
alx
Quartz Composer Blog: http://machinesdontcare.wordpress.com
Music Site: http://www.toneburst.net
I'm sure it's trivial to add logic to test if the plugin is running on a PPC or Intel machine and switch the pixel format accordingly. I wouldn't know how to do that though. Anyone happen to know how you'd test for processor-type in a QC plugin using ObjectiveC/Cocoa?
alx
Quartz Composer Blog: http://machinesdontcare.wordpress.com
Music Site: http://www.toneburst.net
Compositions are (and always should be) platform agnostic (at least for endian issues; video cards, on the other hand, are justified) -- the correct solution to this would be to make the plugin do the endian detection itself.
Further, endianess shouldn't involve any extra executing code, since it's a compile-time constant. As such, you'll typically add a chunk of code that looks like this:
Then you'll have a single universal plugin that just works, regardless of endiness. (Note: the constants may be backwards in the example above)
Interesting....
So the conditional
#ifdef __BIG_ENDIAN__simply detects if the system is big-endian?
I may try adding that to the Image Writer code and see if it works....
alx
Quartz Composer Blog: http://machinesdontcare.wordpress.com
Music Site: http://www.toneburst.net
Adding
(where 'blah1' and 'blah2' are obviously the actual pixel format identifiers I couldn't be bothered to type).
to the plugin code doesn't do it (I get a 'undeclared' compile error).
alx
Quartz Composer Blog: http://machinesdontcare.wordpress.com
Music Site: http://www.toneburst.net
the pound signs are for the compiler, not the program. There is no variable called BIG_ENDIAN, but there's a "compiler variable" (basically an environment variable) so when the compiler builds the code, it'll do those conditional checks, and build the program based on what it evaluates.
Because of this, you can't really use it like a variable as you have (technically you can, but that's not going to give you the correct behaviour).
it should look exactly like the example above (#ifdef, #else, #endif), in the objective-C code.
[edit: in the source code, around line 75 of ImageWriterPlugin.m, you'll have something like this:
-- not sure if I got them backwards or not, haven't tested. it compiles cleanly.]
I somehow assumed you'd written it in some obscure 'other' language, and I was attempting to translate it into what looked like ObjC (from the evidence of the rest of the code). I really should leave the programming to the programmers... Well, at least until my Cocoa book arrives.
;)
alx
Quartz Composer Blog: http://machinesdontcare.wordpress.com
Music Site: http://www.toneburst.net
Thats the right way round, actually.
Compiles OK Works on on my MacBook Pro, so no reason to think it won't also work on a PPC machine.
You are, as ever, a stellar object, Christopher Wright.
alx
Quartz Composer Blog: http://machinesdontcare.wordpress.com
Music Site: http://www.toneburst.net
OK, this version of the Image Writer plugin should work on both PPC and Intel systems. http://158.223.20.36/temp/ImageWriter_UNIV.zip
If it doesn't, you can just download the Intel/PPC-only ones from the URL above.
Thanks again cwright, for showing me how it's done.
alx
Quartz Composer Blog: http://machinesdontcare.wordpress.com
Music Site: http://www.toneburst.net
Actually, I'm still a bit confused here, I'm afraid.
I thought XCode compiled the plugin when you hit Build. In which case, wouldn't it just compile the code in one way if you happened to be building the plugin on an Intel machine, and in another if you were on a PPC Mac (so you'd effectively still get an endian-specific plugin, albeit one that worked on your current system)?
Sorry if it's a stoopid question; I've only ever really worked with interpreted code, so I'm a bit vague on compiled language and their terminology.
alx
Quartz Composer Blog: http://machinesdontcare.wordpress.com
Music Site: http://www.toneburst.net
It's a bit complicated actually. Your mind is in the right place though.
in xcode, if you right click the project, and go into info, you can see some properties, like this:
Note the two architectures, ppc and i386. When both of those are enabled, the compiler will actually compile the source twice, once for each architecture. It'll then glue them together into a "fat binary" (universal binary), and when you run it on your mac, it's smart enough to pick the correct one.
The magic then happens like this: For each architecture (there are actually 4 for Leopard, ppc, ppc64, i385, and x86_64. maybe arm too if you count iPhone/iPod touch stuff I guess), the compiler will have different environment variables that describe the environment. Big Endian is only set on big-endian CPUs, otherwise it's left unset. (There are other variables too, but I can't think of them off the top of my head). This way, the compiler builds the "right" version. An added side effect is that the two binaries are actually a little bit different in what they do. This can be abused -- for example, you could make one whole program, and have it all in an intel-detect block, and then an entirely separate program in a ppc block, so it'd look like one app to the user, but it'd be totally different depending on whether or not they were on ppc or intel. I've not seen anyone do this, but it's entirely possible without any dark hackery.
Oh, OK,
I'd forgotten about fat binaries. Sooo... it's going to compile both, anyway, and you're just telling it to specifically make the pixelFormat different according to endian-ness.
A typically clear and concise answer :)
Thanks again,
alx
Quartz Composer Blog: http://machinesdontcare.wordpress.com
Music Site: http://www.toneburst.net
As we are in writing image to disk land, is it not time to add some little robust option to the image writer patch ?
PNG work well for still capture...but is it the best format to write Image sequence at 25/30 FPS on disk ? what is the best format to do this ? We need a 32 bits format (rgba) and no compression. perhaps 16 or 32bits per channel.... PNG,TGA ,TIFF, PSD, DPX, EXR ?
Yes there is quicktime to do it but the concept of "frame store" is very interesting.... (see quantel "frame magic" http://www.quantel.com/site/en.nsf/HTML/products_keytech?OpenDocument#FM )
any advice and help chris ?
yanomano.
I'm considering using Image Writer to store 'preset images' for my 3D mesh-creator. The idea is, you feed video through it, until you get a mesh shape you like (the video deforms the mesh in realtime), then you can save the deformation image as a preset.
Heightfield images look something like this: http://machinesdontcare.wordpress.com/2008/04/17/spherical-height-maps/ and produce a sphere shape, distorted by the overlaid processed live video image.
Haven't worked out the details yet, though
alx
Quartz Composer Blog: http://machinesdontcare.wordpress.com
Music Site: http://www.toneburst.net
In engineering, "best" is usually too vague to mean anything. I'm guessing you mean "best format to do this" as in "fastest"?
In that case, uncompressed png and uncompressed tga have the least overhead (I used to write tga readers and writers just to practice programming when I was in highschool), so that should go quickly. That said, the images can be huge, and that can cause a bottleneck if your disk is slow. PNG with a little compression might be fast enough to work, and save enough space to not bog down the harddrive. It all depends on image size and content though.
psd and exr have way too much overhead for this, and I know nothing about dpx.
Yes Christopher, sorry for this non-engineering language... I was talking about a good ratio in term of recording speed and quality.The challenge is not the same with a G5 connected with fiber channel to an xserve raid (or with a sata caldigit S2VRHD, to speak of what i know ) and a powerbook G3 with a filled disk...:) There are a lot of design with gradient in QC so 256 greys levels/per channel is sometimes not enough for mastering screenshots or sequences. in video production we work with 10 bits for broadcast (1024 grey levels), SDI video cards are generally 10 bits. For 3D rendering, Tiff 16 bits is cool because it preserve gradients, but this is 4Mo/image in SD (100 Mo/s), so you need a raid for "raisonable interactive compositing work". (I don't talk about 32 bits per channels because I never worked with such a color depth...:)
So my question is : what is the fastest format to be real time recorded on disk and that consume the less CPU ? and with loseless quality PNG, TGA or TIFF ?
I will do some test with after effetcs (rendering animated fractal noise), and i'llcome back with consistents infos.
yanomano.
So i have done rendering tests with after effects and Apple motion (because the time after effects take for recording PNG afraid me ...) (50 Go of space free on disk after the test)
With Apple : TGA and quicktime none or PSD for speed recording !
yanomano.
is png compression enabled? That might be causing the massive overhead (png compression is lossless, but really lousy for most image material -- LZW isn't well-suited for photo-like images). If not, I guess it's a horribly slow library, or apple's implementation is bad. shrugs can't really tell without more testing.
Looks like PSD is much more light-weight than I thought, about the same as TGA. I guess either of those would be good choices.
EXR also has a few different modes of operation, including lossy and lossless, as well as uncompressed. uncompressed EXR should be fairly snappy, but very very large...
i have done the tests with this parameters....(check the screenshot..) is "best" a compression mode ?
yanomano.
I have no idea what those options mean/what they'll do. I imagine they have to do with sampling or something (adaptive is a method of antialiasing, for example), but I don't know how that translates into compression. Maybe do some tests with different options, and check files sizes as well as times?
See http://www.w3.org/TR/PNG-Filters.html for a description of those filters. "Best" probably implies "Adaptive" which probably implies "Mega Slow"..
Maybe try benchmarking based on the "None" filter? ("Sub" and "Up" should be pretty fast too.)
Here the new tests :
it Seems that compression have nothing to do with the "snail write PNG"
conclusion: I think that the image writer dev patch with a TGA or a PSD settings will record frames near real time on disk....
yanomano.
Thanks to all of you! i try the plugin tomorrow.
PRACK at VIMEO http://www.vimeo.com/user423770 www.prackgraphix.com
thanks for having solved this and posted results.