JPG, TIFF or PDF?

Prack's picture

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

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

psonice's picture
Save screenshot?

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.

DanieleCiabba's picture
Developer/Examples/Quartz

Developer/Examples/Quartz Composer/Applications/ ther's an app named "Poster" look at this I hope is useful...

franz's picture
Movie Exporter

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....

toneburst's picture
Image Writer Plugin

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

toneburst's picture
I should add

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

toneburst's picture
And also...

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

cwright's picture
wrong solution

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:

#ifdef __BIG_ENDIAN__
        glReadPixels(0, 0, _width, _height, GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, _scratchBufferPtrFlip);
#else
        glReadPixels(0, 0, _width, _height, GL_RGBA, GL_UNSIGNED_INT_8_8_8_8_REV, _scratchBufferPtrFlip);
#endif

Then you'll have a single universal plugin that just works, regardless of endiness. (Note: the constants may be backwards in the example above)

toneburst's picture
Interesting.... So the

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

toneburst's picture
Hmmm

Adding

if (__BIG_ENDIAN__)
   pixelFormat = blah1;
else
   pixelFormat = blah2;

(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

cwright's picture
#def

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:

#ifdef __BIG_ENDIAN__
   pixelFormat = QCPlugInPixelFormatARGB8;
#else
   pixelFormat = QCPlugInPixelFormatBGRA8;
#endif

-- not sure if I got them backwards or not, haven't tested. it compiles cleanly.]

toneburst's picture
Oh, I seeeee

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

toneburst's picture
Right First Time

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

toneburst's picture
Universal Version

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

toneburst's picture
Still a bit confused...

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

cwright's picture
complicated

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.

PreviewAttachmentSize
BuildArch.jpg
BuildArch.jpg135.57 KB

toneburst's picture
Oh, I seeeee

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

yanomano's picture
Frame store

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.

toneburst's picture
I'm considering using Image

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

cwright's picture
"best"

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.

yanomano's picture
sorry

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.

yanomano's picture
PNG lose !

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 !

yanomano.

cwright's picture
wow

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...

yanomano's picture
png preferences?

i have done the tests with this parameters....(check the screenshot..) is "best" a compression mode ?

yanomano.

PreviewAttachmentSize
Image 4.png
Image 4.png103.67 KB

cwright's picture
no idea

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?

smokris's picture
PNG Filters

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.)

yanomano's picture
png benchmarking ...

Here the new tests :

Apple motion :
250 frames rendering with color noise still image.
 
TIFF RGBA   58s
PNG none RGBA   123s
PNG best RGBA   167s
PNG sub RGBA   125s
PNG up   RGBA   125s
TGA RGBA      21s
PSD   RGBA      19s
Quicktime none   23s

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.

Prack's picture
Thanks

Thanks to all of you! i try the plugin tomorrow.

PRACK at VIMEO http://www.vimeo.com/user423770 www.prackgraphix.com

franz's picture
thxx

thanks for having solved this and posted results.