Description: Image without resolution set should get a default fallback resolution (not based on a screen resolution) Steps to Reproduce: 1. Insert the attached image 2. Dimensions in CM/INCH/MM (not pixels) different depending on screen resolution Actual Results: Dimensions in CM/INCH/MM (not pixels) different depending on screen resolution Expected Results: Pick a random resolution.. say 200 DPI by default. Make in configurable somewhere.. Expert settings or options? Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.0.0.alpha0+ (x64) Build ID: b8fb7ecd9cdbe1898c41eaecd9894df8e8f01e25 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc:
Created attachment 160300 [details] Example file
Adding to UX-Eval.. as it's somewhat related to it..
The attached image has 72dpi and is scaled up to 96dpi. It is 640x480px large which makes it 6.67x5" on my LibreOffice. In case of images with higher resolution it is scaled down. What exactly do you expect?
Created attachment 160316 [details] Screenshot Compress dialog Mac
Created attachment 160323 [details] Compress Screen windows
* The image has no DPI set (in file). Look it up in IrfanView? Maybe GIMP. MacOS shows 72 dpi, indeed. * The same image gets insert in different sizes depending on screen resolution (see the cat in the background, on is bigger compared to the other) * The image should be imported at the same size, and not depend on screen dpi resolution. For example: How should an image behave in a multi-monitor setup, 1 high res other low res.. Calculate the size of the image - lacking a internal dpi - on a default value. Say 200 dpi. Not on maddening screen resolution.
The size is taken from the document and in Windows the size of the image is 17cm (on the rulers) and on macOS the size is 12cm (on the ruler). No idea what that is in inches, but I guess the behavior is correct.
(In reply to Tomaz Vajngerl from comment #7) > I guess the behavior is correct. At least I don't see need for input from UX.
Created attachment 160326 [details] Screenshot Mac Properties
Created attachment 160327 [details] screenshot Mac Properties
Created attachment 160328 [details] Screenshot Mac Compress
Created attachment 160350 [details] MacOS compress dialog
Created attachment 160360 [details] Windows vs MacOS size of Cat on insert
Created attachment 160361 [details] Different crop of the same file depending on screen DPI
(In reply to Tomaz Vajngerl from comment #7) > The size is taken from the document and in Windows the size of the image is > 17cm (on the rulers) and on macOS the size is 12cm (on the ruler). No idea > what that is in inches, but I guess the behavior is correct. Behavior is problematic, sorry can't help it. I created a special meta tracker already for this kind of issue bug 116082 1. Please take a look at attachment 160361 [details] a) crop is off because different image dimensions. (Same issue as bug 115808 for Impress). b) click the cat & Compress it a default settings, it probably changes size (depending on screen resolution) 2) The cat also gets different dimensions depending on inserted on Windows 96 DPI or a Mac with 136 DPI (attachment 160360 [details]). Not really problematic.. but not ideal either. The PNG (attachment 160300 [details]) has no internal/file specific resolution set. So i'm proposing a default DPI for images lacking a file specific DPI.
Let me start with a general remark. If you want to insert an image in a text document, then it is very wise to prepare that image in image editing software (Photoshop etc.), to give it the dimensions and resolution (in dpi) that you want. That way, you can insert the image as-is, and you don’t have to use Writer to modify its properties. I recommend Affinity Photo for this purpose, it is cheap, and functionally comparable to Photoshop. You also get free updates. Back to the problem. An image has a size in pixels, but not in cm or inch. The dpi setting in the Exif header will tell software like writer how big the image should be in the document. This dpi setting is just a kind of comment, comparable to your name in the header as copy right holder. If you change the dpi setting, the size of the image on the page will change obviously, but (and this is important) nothing is done (or should be done) to the image itself. Often the dpi setting in the Exif header is 72 or 96 dpi, camera’s will add that setting. It is a rather silly setting. Now, what should happen if you insert a picture that would be to big for the page, let’s say that with the dpi setting in the header, it would be 20 inch of 50 cm wide on a page with 17 cm between the left and right margin. Should Writer keep the dpi setting, and reduce the number of pixels in the image to get the image fitting between the margins? NO, NO, NO !! Writer should change the dpi setting, and leave the image itself untouched. Further manipulations with the size (in inch or cm) of the image on the page, should also just change the dpi setting. When you’re finished with these manipulations, then you should have a look at the resulting dpi setting. Let’s say it is 1000, that is a rather silly dpi setting for a printable page. Then you can reduce it to 300 dpi (for instance), and Writer will recalculate the number of pixels and actually change the number of pixels. What if an image has no dpi setting in the header? Simple, let Writer fit it between the margins, and let it calculate a dpi setting. Remember, the dpi setting is just comment in the Exif header. Then adjust the size of the picture, and when you’re done give it the dpi setting you require and let Writer recalculate the pixels. In other words, I don’t think adding ‘just’ a dpi setting of for instance 200 dpi is the best solution for your problem.
(In reply to Dirk Munk from comment #16) > Let me start with a general remark. If you want to insert an image in a text > document, then it is very wise to prepare that image in image editing > software (Photoshop etc.), to give it the dimensions and resolution (in dpi) > that you want. That way, you can insert the image as-is, and you don’t have > to use Writer to modify its properties. Yes/ no, not everybody works this way. Have seen enough images without DPI from various users.. > > Back to the problem. An image has a size in pixels, but not in cm or inch. > The dpi setting in the Exif header will tell software like writer how big > the image should be in the document. This dpi setting is just a kind of > comment, comparable to your name in the header as copy right holder. If you > change the dpi setting, the size of the image on the page will change > obviously, but (and this is important) nothing is done (or should be done) > to the image itself. > > Often the dpi setting in the Exif header is 72 or 96 dpi, camera’s will add > that setting. It is a rather silly setting. Now, what should happen if you > insert a picture that would be to big for the page, let’s say that with the > dpi setting in the header, it would be 20 inch of 50 cm wide on a page with > 17 cm between the left and right margin. Should Writer keep the dpi setting, > and reduce the number of pixels in the image to get the image fitting > between the margins? NO, NO, NO !! Writer should change the dpi setting, and > leave the image itself untouched. LibreOffice does nothing to the image file itself.. Only after compress.. So no data is lost at all My issue is about dimensions of the image on insertion. If an image file is lacking a embedded DPI setting the "Original size" is calculated on screen DPI.. On insertion it shrinks between the page margins (increasing the DPI). The original size of in image being actually intended as 300 DPI (without being embedded) will result in large "Original size" The cat shape is imported within page margins on my 96 DPI system ( so actual size on screen 16,93 cm x 12,70 cm) The same file imported from a mac with 135 DPI screen results on an image in document size at insertion of 11,95 cm x 8,96 cm). So the 'actual dimensions" are based on screen resolution.. While the apparent dimensions are based the 'actual size' of the image in the document. [How confusing can actual actually be terminology wise] > > Further manipulations with the size (in inch or cm) of the image on the > page, should also just change the dpi setting. When you’re finished with > these manipulations, then you should have a look at the resulting dpi > setting. Let’s say it is 1000, that is a rather silly dpi setting for a > printable page. Then you can reduce it to 300 dpi (for instance), and Writer > will recalculate the number of pixels and actually change the number of > pixels. > > What if an image has no dpi setting in the header? Simple, let Writer fit it > between the margins, and let it calculate a dpi setting. Remember, the dpi > setting is just comment in the Exif header. Then adjust the size of the > picture, and when you’re done give it the dpi setting you require and let > Writer recalculate the pixels. > > In other words, I don’t think adding ‘just’ a dpi setting of for instance > 200 dpi is the best solution for your problem. It's about the DPI for calculating the size of an image on insertion when the file is lacking a embedded DPI. There is no actual manipulation of the image.. Shrink the image afterwards, will decrease the dimensions and increase the DPI. Enlarging the image will increase the dimensions and decrease the DPI from 200 to... This would also "solve" the cropping issue of images on screens with different resolutions. However, this wouldn't fix older documents (or probably make it even worse; so probably something more nifty thing is needed)
(In reply to Heiko Tietze from comment #3) > The attached image has 72dpi and is scaled up to 96dpi. It is 640x480px > large which makes it 6.67x5" on my LibreOffice. In case of images with > higher resolution it is scaled down. > > What exactly do you expect? @Regina I would you mind to explain - again - the whole dimension/DPI handling for images without resolution set. The PNG in the document has no 'internal' dpi... See (for example) IrfanView. MacOS shows it at 72dpi.. Or make clear that I'm wrong of course..
(In reply to Telesto from comment #18) > @Regina > I would you mind to explain - again - the whole dimension/DPI handling for > images without resolution set. The PNG in the document has no 'internal' > dpi... See (for example) IrfanView. MacOS shows it at 72dpi.. And for me the image is shown at 120dpi, because that is my display setting. If I change my Windows 10 to use 96dpi, then the image is shown at 96dpi. LibreOffice uses what ever dpi is set in the OS, in case the image has no dpi info. But the user cannot see, that the image has no own dpi information. So it might be useful to change the text in the crop tab of the Image properties dialog. For example instead of (120dpi) write (unknown dpi, using 120dpi OS default). In file format only the current size and the crop-values are stored. LibreOffice does not change or set a dpi-value at the image.
(In reply to Regina Henschel from comment #19) > (In reply to Telesto from comment #18) > > @Regina > > I would you mind to explain - again - the whole dimension/DPI handling for > > images without resolution set. The PNG in the document has no 'internal' > > dpi... See (for example) IrfanView. MacOS shows it at 72dpi.. > > And for me the image is shown at 120dpi, because that is my display setting. > If I change my Windows 10 to use 96dpi, then the image is shown at 96dpi. > > LibreOffice uses what ever dpi is set in the OS, in case the image has no > dpi info. But the user cannot see, that the image has no own dpi > information. So it might be useful to change the text in the crop tab of the > Image properties dialog. For example instead of (120dpi) write (unknown dpi, > using 120dpi OS default). > > In file format only the current size and the crop-values are stored. The issue is, corp is depending on size. The image has no 'size' without DPI. So crop is broken when switching between resolutions. So only a message won't solve the problem. And the original size would still be 'random' depending on screen DPI. Will talking about DPI: Save image 1. Right click an image -> Save -> Choose file name & PNG & Press save 2. PNG options dialog popups up.. also having an resolution setting 3. Save the file -> open it with Irfan view -> DPI Resolution isn't written Compress image 1. Right click an image & choose compress 2. Pick a resolution: 300 DPI and an image size 3. Press compress 4. Save the file 5. Rename the ODT to zip & and extract the image 6. A DPI resolution is written.. but not my pick. 72 x 71 (really 71) DPI
(In reply to Telesto from comment #20) In case the user changes the resolution, this resolution has to be written to the image. In case the user does not touch that field, the image should not change in that respect, which means would still be empty for the "cat"-image. > Save image > 1. Right click an image -> Save -> Choose file name & PNG & Press save > 2. PNG options dialog popups up.. also having an resolution setting > 3. Save the file -> open it with Irfan view -> DPI Resolution isn't written I can confirm that. Please write a bug report. It works in Draw, if you use File>Export instead. > > Compress image > 1. Right click an image & choose compress > 2. Pick a resolution: 300 DPI and an image size > 3. Press compress > 4. Save the file > 5. Rename the ODT to zip & and extract the image > 6. A DPI resolution is written.. but not my pick. 72 x 71 (really 71) DPI I can confirm that. Please write a bug report. > The issue is, corp is depending on size. The image has no 'size' without > DPI. So crop is broken when switching between resolutions. So only a message > won't solve the problem. And the original size would still be 'random' > depending on screen DPI. There might be an error in the way LibreOffice has implemented "crop". I will look, how it is specified in the standard.
Is there a reason to still keep this open? Has this branched into actionable reports?
(In reply to Buovjaga from comment #22) > Is there a reason to still keep this open? Has this branched into actionable > reports? This is still valid in my opinion. The problem is that there are images without embedded in file resolution (even written by LibreOffice itself). So LibreOffice uses a fallback resolution to calculate the image dimensions; as they are lacking in file. The fall back size is based on screen resolution (DPI) on file open.. As LibreOffice doesn't touch embedded image files (without resolution) even this resolution isn't written inside the image. Still blank. So document on a system with HiDPI will calculate different measures (based on screen DPI) as a file DPI is still lacking. Breaking for example crop. There are options. So import at a fixed resolution (maybe with export configurable setting) if the file lacks embedded meta data about DPI. Or keep the current system using display resolution, but written inside the file on save. However this is problematic, because of external linking of images etc. So still propose a fixed resolution only in the case where they resolution meta data being empty. Where fixed means pre-defined default. I considered expert setting to change this, but probably again a bad idea. As the problem can be re-introduced if people change the default. And if it where up to me somewhere around 200-300 dpi. 96dpi is bit low for printing etc. The only problem here is backward comp-ability. The document is fine as long as you use the same screen resolution. So setting say 300 as default will break crops for images without resolution created prior to change if a resolution is lacking.. So not sure how to get out of that dilemma. There will be a problem anyhow at the time everybody moves to HiDPI screens.. Or someone must have some nifty fix for that too. Basing image resolution in document size of the image? And seems to me that this being actionable as such. Problem is more how
Practical example of downside of the current implementation: bug 137049
Why don't you use a free program like Exif Pilot to set the dpi before you insert the image?
Apart from the title, I don't see a value in this Unconfirmed bug over bug 52598 and bug 96178, please explain.
*** This bug has been marked as a duplicate of bug 52598 ***