ImageFilterPipeline now loads arrays properly.
Merge branch 'master' of https://github.com/BradLarson/GPUImage

Conflicts:
	framework/Source/GPUImageFilterPipeline.m
For large images, now conserves memory by deallocating framebuffers the instant they are no longer needed. Somewhat experimental, so things might break.
Merge branch 'master' of https://github.com/BradLarson/GPUImage
Fixed a crashing bug with still images.
GPUImageTextureOutput had the wrong type for the texture property.

Was GLint should be GLuint.

Signed-off-by: Karl von Randow <karl@xk72.com>
GPUImageOpenGLESContext: change singleton construction so you can subclass

Signed-off-by: Karl von Randow <karl@xk72.com>
GPUImageOpenGLESContext: enable subclasses to override the context

Signed-off-by: Karl von Randow <karl@xk72.com>
GPUImageOpenGLESContext: add EAGLSharegroup capability

Call [[GPUImageOpenGLESContext sharedImageProcessingOpenGLESContext] useSharegroup:[existingEAGLContext sharegroup] before you use GPUImage (ie. before the GPUImageOpenGLESContext's own context is created)

Signed-off-by: Karl von Randow <karl@xk72.com>
GPUImageOpenGLESContext: tidy added methods

Signed-off-by: Karl von Randow <karl@xk72.com>
Merge pull request #609 from karlvr/sharegroup

EAGLSharegroup support
Merge pull request #608 from karlvr/bugfixes

GPUImageTextureOutput had the wrong type for the texture property.
Merge pull request #579 from Vokl/master

GPUImageFilterPipieline now loads arrays
Fixed a lagging issue with live updates of filtered still images. Fixed a minor memory leak within the video camera.
Add a property to set the JPEG compression quality to use when capturing a JPEG from the camera.

Signed-off-by: Karl von Randow <karl@xk72.com>
doing my best to DRY up capturePhotoAs* methods of GPUImageStillCamera
extra check to preempt trying to capture two still images at once
GPUImageVideoCamera makes the metadata from the image capture available during the capture completion handler
Bug fix: textureNoLongerNeededForTarget would release texture before all the initial filters in a filter group had used it

This problem manifests when shooting photos (ie. the conserve memory is active) and operating a chain of filters (eg. camera -> sketch -> tilt shift) where there is a filter group with multiple input filters after another filter (as above). One of the filter group's initial filters would get an empty input texture as the texture would be released early.

This is because the outputTextureRetainCount is based on number of targets. But a filter group target actually represents initialFilters filters (ie. possibly more than 1).

This change proxies delegate callbacks to textureNoLongerNeededForTarget from initialFilters in a filter group, through the filter group so it can run its own "retain count", before telling the actual delegate to release the texture.

I have tested this with a simple example of Camera -> Sketch -> TiltShift (which is a filter group). The problem appeared when you shoot a photo - the tilt shift would have the blurry bit intact but the in-focus part of the image would be black (as the texture was released).

This problem is now corrected and the same number of textures are released (so they are still being released, just later).

Signed-off-by: Karl von Randow <karl@xk72.com>
Merge pull request #631 from karlvr/textureNoLongerNeededForTarget

textureNoLongerNeededForTarget would release texture before all...