Hacker News new | past | comments | ask | show | jobs | submit login

For those who would be interested in downloading the picture, or other images using the same technology, I maintain a set of opensource zoomable image downloaders :

- dezoomify : https://github.com/lovasoa/dezoomify (a browser-based tool that recreates the image as an HTML5 canvas. Limited by the maximal size of canvases in browsers)

- dezoomify-rs : https://github.com/lovasoa/dezoomify-rs (a command-line utility that can download larger images, including the one presented in this post)

- dezoomify-extension: https://github.com/lovasoa/dezoomify-extension/ (a browser extension that finds zoomable images in web pages and allows downloading them with dezoomify)

If you are passionate about high-resolution art and know javascript or rust, you can come contribute !




Hi, I'm the creator of the image and of the Curtain Viewer technique and software. Please note that this is hosted on my personal AWS and that I pay the hosting costs out of pocket.


Thank you very much for creating this tool. I once looked into into doing the same but lost interest. Really great to get some Egon Schiele in high resolution format!

One suggestion: Print out WHERE the image is saved after downloading, I had a hard time realising it's sitting in the root of my home folder...


In dezoomify-rs, the place where the file is saved is displayed when the file is downloaded.

In dezoomify, the application cannot know where you saved the picture, since the browser does not share the location of the download folder with webpages.


dezoomify-rs shows the following message (MacOS): "Saved the image to Kneeling Girl_ Resting on Both Elbows - Egon Schiele.jpg"

No folder/path visible here.


Oh yes, I see. The path is shown relative to the current working directory.


Perhaps it's relative to the application's current working directory?


Binary is in ~/Downloads/dezoomify-rs/, image was saved in ~/.


Unix programs start, not in the directory that their binaries are in, but rather in the directory that their parent processes are in. That could be the directory of the binary if the parent process did a chdir(2) there before spawning the child, but command-line shells never do that unless the user explicitly typed "cd".


It is relative to the current working directory, which is not necessarily the same as the directory the binary is in. We could display the full path, though. Interested in making a PR ?




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: