-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add optional scale/width/height to query in image.php #1000
Comments
This is a good feature to have. zmNinja uses view=image to apply authentication over event frames without the (current) overheads of zms. Till the time zms is fixed to a) return a single image for an event b) validated that it does not have any significant overhead compared to this method, I personally don't see any reason why this new addition should be a problem for what it does. |
Thanks, I've pushed a change to permit either width or height or scale in combinations. |
Seems to work fine for me. @Linwood-F you can always make (optional) changes to the algorithm in later pushes if you want, but its useful to have as it stands today. Would you want to request folks to merge it? |
Yeah, as you saw offline I experimented with the other techniques and did not see improvements (and one of them crashes php consistently), so i think this is ready, will post a note in the pull request. |
PR was merged. Can we close this issue out? |
Sure, sorry, still learning the steps. |
No problem. Thank you for all the work you've done for the project. |
The image.php is used to return a single historical image. It is currently an alternative to direct access via the /events... path, the latter of which is a security issue and seems doomed to going away. The image.php is an alternative, though in the future I am a strong proponent of incorporating historical access to single frames in zms instead. However that is a large task, and image.php is already used and simple, and more relevant is being incorporate in new programs.
This issue is to incorporate scaling as an option in this program. There is a tradeoff in doing so, in that scaling on the server puts load there, but removes potentially very large bandwidth requirements if clients pull data with an explicit scale (as opposed to pulling the whole image and then scaling in the client).
The text was updated successfully, but these errors were encountered: