-
-
Notifications
You must be signed in to change notification settings - Fork 68
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
Preserve the image DPI information from individual tiles in the final output #12
Comments
Hello,
A more interesting feature would be to allow the user to specify the quality parameter that is passed to the JPEG encoder for the final image creation (this feature was recently added to gapdecoder). If you are interested in that, feel free to open another issue. |
If your request was indeed about DPI meta-information that is lost during dezooming and not image quality, then you can re-open this issue. |
Thank You very much, @lovasoa for Your promptness and for having kindly reported me about ExifTool and the system to recalibrate the parameters ...
... although in substance it took almost half a day 🙄 to understand how it worked both for a single image and for a whole folder, now I know how to correct the DPI problem. Anyway, I know that DPI is a meta-info and has nothing to do with images' quality. You also write:
I don't know whether to do it or not: what I regret is that the original DPI. |
What exactly do you need the dpi information for ? |
The people I work with are meticulous: if maps are available at 300 dpi, they prefer that; and, since Milan & Venice State Archives have upload them at 300 dpi, I wanted to rectify this metadata. |
Ok, I'm reopening this, then ! Currently, the libraries we use do not have support for custom DPIs, but that's changing :
|
I'm glad to have aroused so much interest in the GitHub community, @lovasoa. |
dezoomify-rs uses what is called a software library to read and write JPEG files. The code of this library is not specific to dezoomify-rs, but is shared with many other projects. Once a new version of the library is released, and adds functions to read and write pixel density information, we will be able to use these functions to implement the functionality you wanted in dezoomify-rs. This may take a long time. |
Okay, that's fine @lovasoa: in the meantime that You experts 🧐 work on the software library, I'll use exiftool, as kindly indicated from You. Thanks and good work to everyone! |
Any update on this? :) |
The image library that we use, image-rs does not have any generic support for meta-information on image files. It can write DPI information (on jpeg files only), but not read it. @Boscop: If you want to add support for this, the work starts in these external libraries: image-rs, jpeg-decoder, and other image format libraries if we want to support this feature for them too. |
All dezoomified maps (small and/or large) are at 96 dpi, although some are reported as 300 dpi. I did a test with this small-sized map from BNF Gallica, dezoomifying it first directly (obtaining an image at 300 dpi), then with dezoomify (obtaining an image at 96 dpi)😯. Same for other maps, not only from BNF.
This is even more true of dezoomify-rs: the large cadastral maps of Venice and Milan State Archives were uploaded at 300 dpi (archival authority confirms this fact), but are dezoomified at 96 dpi.
Why?
Are the two softwares calibrated exclusively at 96 dpi?
If so, is there a way to get the image at 300 dpi🤔?
Warning: I underline that the images to which I refer are really very large, so Photopea and Photoshop Portable freeze if I try to (re)convert them to 300 dpi.
The text was updated successfully, but these errors were encountered: