|
|
QCrystal, HDR, and 64-bit
Additional Features:
Weaknesses:
So, to sum up, is 64x antialiased, 1024x temporal supersampled HDR rendering desired by anyone? Is the additional complexity of an additional app worth it to you? What's HDR? 0% (0 votes) No, I use another tool to accomplish this task. 0% (0 votes) No, I don't use HDR 0% (0 votes) Yes, I need this 0% (0 votes) Yes, I want this 0% (0 votes) Total voters: 11
|
We're interested to know if there's any demand for a 64-bit version of QuartzCrystal -- such a version would have a couple additional features, and a few weaknesses.
Actually, I was about to ask just the opposite.
I'm doing something where I've written something like a line-art filter in CI. It looks like attachment1 in quartz composer. When I render it with crystal (or play it in quicktime - it's the same), I get nice smooth blocks of colour (like attachment2). Any idea why?
What are your render settings? Can you send me the composition for testing (I won't publish it)?
There are some bugs in CoreImage where images with dimensions > 2048 start doing weird things, so if your screen size is >2048 pixels wide (QuickTime renders the composition at your screen's size), or if you have Antialiasing turned up in QCrystal, you can hit this limit, and it starts acting weird. This doesn't quite look like that, but it's difficult to tell.
Try rendering without AA or MB, and see if that changes anything.
Maybe this also could be a difference between hardware and software rendering? (Looks maybe like an exposure-level issue, which I've seen differences between CI in hardware and software.)
I'm guessing the QuartzComposer Editor is probably rendering in hardware, and QuartzCrystal may be using the software renderer?
I get very mixed results on this machine (an old g4 powerbook with radeon 9700).
Using the 'emboss' patch: glitches in a really cool way in QC (it's somewhere between line art/contours and emboss), in crystal or ANYTHING else (quicktime, quicklook etc.) it works normally. Fine, just a glitch in QC perhaps..?
Using a CI filter I've written to reproduce the 'contour' effect the emboss gives me (does a basic luminance compare with an adjacent pixel, and draws the pixel if it's higher): works correctly in QC, looks like a cartoon shader in anything else. Urgh!
Anyway, the deadline was hours ago, the competition is in 3 hours or so, and I've not finished, so I'd better crack on and make do with whatever appears on screen :D (I'm at Sundown - a demo party in devon, UK \o/ )
Try dropping your frame rate to whatever it is running at in your QC Viewer on average.
A few things I have noticed that will resolve issues...
Going back and tweaking blend modes. I was achieving a color swirl in a .qtz that wasn't getting the correct color transform. When I changed the blend mode, it rendered correctly.
Making sure that I'm not driving any of the parameters outside of their available ranges using lfo's, interpolation, etcetera. That won't always cause problems, but it has when I have done this using some of the GLSL patches. I have also really screwed some stuff up doing the same with the Freefame filters. Somehow I think that driving the plugin stuff outside of its available ranges is more susceptible to crashing, especially when juicing the antialiasing. What I mean by outside of the range is, if a node has a throw of 1~10, connecting it to an lfo that generates numbers +10.
I also notice that some of the "look" of some compositions was coming from it running at low frame rates...
It is worthwhile experimenting with the different encoding styles, as they can make a real difference in the end look. Some things just don't look as good in H.264, but oddly some look better.
The anti-aliasing is also totally unneeded with certain qtz., imo.
Just my $.02.
To date, the only crashes reported in QCrystal as of 1.2 are out-of-memory crashes -- these are caused for 3 reasons:
1) Turing antialiasing up very high uses lots of ram: worst case is ~2GB per frame, which is about the most a normal 32bit app can allocate (and that's not including room for QuickTime, Quartz Composer, and the user interface). This can't really be worked around without switching to 64bit.
2) CoreImage uses excessive amounts of memory when motion blur is enabled. This is because of a misfeature in CoreImage, and we're testing workaround to address this.
3) Even if you're free and clear, memory-use-wise, QC and QT allocate lots of small objects each frame, and as those get scattered around, the amount of contiguous free memory for the process gets smaller and smaller (i.e. it could have 700MB free, but in 700 separate 1MB chunks, so you can't allocate anything more than 1MB.) There's no solution to this either (and this has been a problem for computer programs since dynamic memory allocation became fashionable).
Invalid/out of range inputs either get clamped to a specified range limit, they get interpreted and produce wrong (but non-dangerous) results, or they throw an exception (which, as of 1.2, should get caught and gracefully handled without a crash). Badly coded plugins could also crash QCrystal, just as they can crash quartz composer, or any other QC-using application.
QuickTime's codecs are a quagmire of color-correction insanity. Each codec performs its own color correction (and each one can (and often does) have a different reference colorspace, which gives subtly different color transforms while encoding, and upon playback. Also, MPEG-based codecs (Mpeg4, h264) don't handle bright reds particularly well, and many subsample chroma, which looks bad around highly saturated colors on dark backgrounds.
Putting everything inside a render in image, then disabling color correction (curse it's very name!) made everything grainy and dark instead of washed out. The glitching still happens inside QC but not in crystal or quicktime though, dunno what causes that.
Anyway, the demo got made, the compo is over, and I've released it. I'll put it up on the examples bit of the forum for anyone interested.
I would like to check that out when you get a chance...
http://kineme.net/Applications/Compositions/Numbersnewdemosceneproduction
I think I didn't vote on this, as I was under the impression that it wouldn't affect what I'm doing really. Then last week I went back to the slit scan stuff.. the composition that regularly kills crystal due to serious memory thrashing, and remembered that yes, it most certainly does!
Anyway, if I'm right in thinking 64bit crystal would help in that case, count me in the 'yes' camp!