Added the ability to specify the image resolution and various other fixes an enhancements #37
Conversation
… image size. - added requestedImageSize property, defaults to CGSizeZero, which means largest possible size - when possible using capturePhotoAsImageProcessedUpToFilter:withCompletionHandler: to get the largest possible image size for the current device - setting up a custom capture filter chain that crops (and resizes) the hi-res image, while still using as little memory as possible
- this seems to be the current convention
- improves cocoapods support - checks for a renamed class in older GPUImage versions
- implemented a better method to show the image library if there is no camera available (showing only once per picker invocation and without any delays) - the UI can now stay visible if there is no camera available (camera-related buttons are hidden, no need to dismiss the picker if we don't select an image in the image library)
|
Hey @matej thanks for submitting this. I used to have full resolution capture but folks complained of crashes so in the repo version I set it down a notch. I will run this over and get back to you, but for the most part it looks like refactoring, yes? Also, how does it perform with another filter added in the chain to force the sizing? |
|
I observed a lot of crashes during development, mainly due to very high memory usage. I than spent quite some time in Instruments, tacking down memory problems and figuring out the best GPUIMage configuration and settings. This lead to the code I submitted, which works pretty well for me. Yes, there is some refactoring in this pull request as well. I have added prefixes to some reusable classes to avid namespace collisions and did a few tweaks now and then but nothing drastic. I also tried to maintain the code style. I'm not entirely sure I understand what you're asking in your last question. I didn't notice any significant performance problems. During the preview stage the images returned from the camera are fairly small, so it performs just as before. After the capture the filters are applied to more-or-less static content, so filters still be applied quickly enough. It wouldn't probably be a problem to add something like this to the static filter chain to scale the image down to the actual pixel size of the preview view and to get even better performance. |
- filters and ui (xib) - those resources can bow be skipped if the host application provides it's own resources
Added the ability to specify the image resolution and various other fixes an enhancements
|
Sorry this took so long. Great work cleaning stuff up. |
Here are a few fixes and enhancements, that I've accumulated while integrating this great component into a new app. Some of them might be useful for a broader audience, so feel free to merge this in or just cherry pick stuff that seems useful.
The main improvement is the ability to efficiently capture hi-resolution images (with the appropriate asynchronous GPUImage calls and fallbacks) and to specify the exact desired size of the final images (or to get the maximum possible size if not specified).