Well, that's the likely intent of many of the convenience pre-setup filters included with 10.6+ that use qc to create the instruction chain to prep the image.
QC has the ability to load patches and plugins, and the core image filters it loads are actually units that live in the core image framework, largely. In that sense it would be a request of core image functionality, I believe.
The problem is that one doesn't really need to always crop at every step of an image filter chain. It probably wouldn't be great if each image unit had to make a check to see which route to take(crop or non-crop) for every single image unit placed in a chain; that kind of pattern usually leads to bad performance when scaled to large projects.
Cropping at the end of a filter chain also sets the area that the rest of the chain upstream acts on, which can help performance.
Sent from my iPhone
On Sep 8, 2011, at 9:02 AM, Keith Lang <email@hidden
I'd love a checkbox for 'output size equals input' on patches to avoid the crop dance.
On Thursday, September 8, 2011 at 8:59 AM, George Toledo wrote:
That is a side effect from the gaussian kernel.
If you look at look at a simpler blur kernel, like a box blur, you will see that you take multiple samples of an image, and offset them by a pixel (or more) up/down/left/right and blend together. If one does this, the actual edges of the image end up having a kind of edge because there aren't pixels available "outside the bounds" of the image for the blur kernel to work on. Also, because one has kind of created and shifted these multiple planes of image data up/down/left/right, your image extents will now be larger. This is really easy to see with a simple box blur (each sample), but this is basically what you're seeing with the gaussian blur as well.
One easy route to a fix would be for you to just use the "blur" composition that is in your patch list (if you're using 10.6+). Also, If you have this, look for the source file at the location described in the patch list, and examine the process that is taken in that composition to properly setup the image to be cropped. If you follow that pattern for other core image kernels that have this kind of side effect, you will be pretty solid most of the time. Usually, one uses a crop patch referenced to the image dimensions of the source, and sometimes incorporates something like an affine clamp to extend the image if needed.
On Thu, Sep 8, 2011 at 11:42 AM, Sebastian Mecklenburg <email@hidden>
OK, I'm getting closer. I have my shape generator up and running and it looks fine.
However, I created my image just big enough to contain my shape, so when I apply an image effect like "Blur" the image appears to be cropped. I think, the image should be extended so it can fully contain the blur halo. Is this something I have to take into account as a programmer or is this the expected behavior and the user has to deal with it? I noticed that the "Gaussian Blur" effect seems to shrink the image to be blurred beforehand to make room for the blur halo, but I don't like that.
Thanks and regards,
Do not post admin requests to the list. They will be ignored.
Quartzcomposer-dev mailing list (email@hidden
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden