-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Thumbnail generation: does not obey aspect ratio / max values for x and y #16250
Comments
Could you give some detailed examples of what you mean? Also, bear in mind that there is this problem: #14712 |
I will try. :) But if the original size is: 1024x1280 (landscape) Regarding #14712 I do not think that problem applies here as the desired size is always smaller than the original size. Thank you for your very quick reply! |
So, in your first example (which is landscape), you end up with an image which is exactly 320x256 and where there has been no cropping since the ratio is exactly the same. And in the second example, you end up with a 320x256 "extract of the image, but you would like to get a 205x256 image. Correct? I think the problem is that the public interface of preview does not have the setKeepAspect() method. One thing which may slow things down is that this would require changing the API to introduce the aspect ratio flag. |
Oh. My fault. To clarify: The thumbnail api seems not to the x and y values as maxX and maxY. Instead it crops (if neccessary in landscape) the image. |
Any updates on this? Maybe this should be not a thumbnail route but a resizedImage route as these are not really thumbnails...? Then we could avoid the problem of changing the api... |
Could you try #16382 and see if it changes things for you? You may need to clear your thumbnail cache or test it with new pictures |
Unfortunately it does not help. I would expect an image with 300 width and (450/2)=225 height and nothing being cropped. I do not know how you want to handle thumbnails: Thank you very much for your help! |
I'm sorry, I should have re-read what I wrote earlier. Your problem is that it's going to be difficult to ask people to install a separate app, unless this is an additional feature in the app and so people will do what needs to be done to get it working. |
This should be in /core as it is now with the thumbnail route. So my idea is to modify apps/files/controller/apicontroller.php:70 Then it would not change the current API as it is an optional parameter. |
Any updates on this? Thank you! |
The fix is in this unmerged PR: #18675 |
The PR suggests to wait to OC9? This is very long, or? What about my suggestion to extend the current API with an optional parameter? |
Gallery is automatically installed from 8.2, but it's true that an admin could decide to disable it, in which case you could fall back to the broken behaviour.
Too late as we're past feature freeze. |
Then Gallery will be the way to go, I guess. |
Update: I got it partially working with 8.2. |
I guess you've figured out how to get the IDs :) Regarding the app store version, there are two problems:
|
Regarding the IDs: There is a strange behaviour with the android app. The getFileId() function delivers an id value that does not match the value in mysql -> oc_filecache -> fileid for the same file. But https://tobi:[email protected]/owncloud/index.php/apps/galleryplus/api/preview/23379/400/300 is working and respects the ratio and max values as I need it. So basically this can be closed (although it would be better to have a fool proof way as the admin can still disable the app and then brake the system). |
:S That's strange, maybe there are 2 Ids, the local one, which may not have been uploaded yet and the remote one.
Nice. The only caveat is that this endpoint does not let you set the aspect ratio. So it respects it as this is what is needed for a "preview", but you can't ask for one without it. The API can evolve, of course, since the thumbnails endpoint is streaming back thumbnails and some clients can't capture that stream.
I'd say, keep it open until the WebDAV preview endpoint has implemented all the needed features. Hopefully in 9.0. |
Yes. There seems to be an internal id. I tried to add to your app an additional route which accepts the file path, but all I get is a Would be great, if you can help me out as I have no experience with owncloud and php. |
I initially misread your post... If you add a route, you need to add the proper method to the controller, including the special tags. But I'm not sure this is the best way forward, as it would require making permanent changes to Gallery... I'm guessing the problem you're having is that the Android app is using paths as IDs? |
My main problem with changes right now is that if they're too big, they're not going to be in 8.2 and that's going to be a problem for you. I could probably squeeze in an extra parameter like path="/dir/file" |
I was thinking about this route: On android I have
Therefore I thought it would be the easiest to use the remote path. |
Unfortunately, it will, so does adding a new path parameter. It means adding a new test as well. Those are the planned changes for 9.0: |
With the help of IRC I have found out that the android app already gets the file id. So, we are done here for now. Thanks again for your help! |
Excellent news! |
@oparoz any news on the webDav preview endpoint? |
@tobiasKaminsky - Nope. @PVince81 Is it planned for 9.1? |
If I read correctly the related issues, this is dependent of feature:preview. Daring to label... |
Hello,
i am currently developing for our android app the posibility to only download reduced images instead of the full sized images.
Therefore I use the following url address to download the image file:
http://localhost/owncloud/index.php/apps/files/api/v1/thumbnail/244/326/bild.jpg
The problem is that a landscape oriented image will get cropped as the x-parameter is smaller than y. But on the client I do not know whether it is landscape or portrait.
So the best for me would be that I specify a max x and max y with the url and get an image that fits these requirements:
on portrait this would be the same
on landscape the thumbnail generation system must obey the x size and scale the image to the requirements.
I have looked into it, but unfortunately I could not solve it.
Can someone help me?
Of course I can try any patch.
Thank you
The text was updated successfully, but these errors were encountered: