Please provide a step by step scenario to reproduce your problem.
http://wiki.documentfoundation.org/BugReport

Best regards. JBF

Created attachment 64820 [details]
The example .jpg picture with 600 dpi

Created attachment 64821 [details]
My own default template for Writer

See the 2 attachments. The bug happens in all cases:

Start Writer, if already running, open a new document (Ctrl+N).
Menu Insert/Insertion: Picture: from file. Or: with drag and drop with the mouse, from the Windows Explorer (File Manager) to the document, or maybe with opening the picture with the Writer, I did not try it. But I tried: munu Insert/Insertion: File.

Windows XP Home SP3 Hungarian.
Because of Writer uses the display resolution, if I open the saved file in an another computer, the picture size can vary. For example, the most common display resolution is 96 dpi.

Created attachment 81120 [details]
made on my 1600x900 monitor, with the screen resolution set as 800x600

Created attachment 81121 [details]
made on my computer with the 1366x768 screen

Created attachment 81122 [details]
on my computer with the 1600x900 monitor, with the screen resolution set to its normal resolution

Computer 1: operating system: Windows 7, LibO version: 4.0.3.3 release (1600x900 screen)
Computer 2: operating system: Windows 8, LibO version: 4.0.3.3 release (1366x768 screen)

Here are the steps I took to create the attached documents:
0. I downloaded your default template and the example .jpg picture.
1. In Windows Explorer, I double-clicked your default template.
2. menu Insert > Picture > From file, selected the picture
3. I saved the file.

My attachments' titles show within parentheses the screen resolution in which the document was made. (e.g.: "Picture Bug (1366x768)" was made on my 1366x768 computer). For the "Picture Bug (800x600)", I changed the screen resolution of my 1600x900 monitor.

I can't reproduce the bug, but that might be because I don't understand what you mean by "picture size". So what do you mean by picture size?
A. the size according to the LibreOffice onscreen ruler? In the combinations [800x600 screen and 800x600* document, 1600x900 screen and all three documents**, 1366x768 screen and all three documents**], the onscreen ruler shows the picture as slightly less than 4 inches high.
B. document size? All the documents are ~416 KB, though their sizes are different by a few bytes.
C. how many pixels are in the picture? For all the documents I attached, I performed these steps:
  1. I right-clicked the picture, selected "Edit with External Tool"
  2. Windows Live Photo Gallery opens. File > Open with > Paint
  3. The Paint status bar says "3200 × 1688 px"

* "800x600 document" refers to the document named "Picture Bug (800x600)
** the three documents I attached

I'm not sure whether this bug involves data loss, so I'll keep the Importance the same.

Because I need a clarification about what you mean by "the picture size can vary", I'm changing the status of this bug to NEEDINFO. When you make the clarification, change the status back to UNCONFIRMED. Thanks for reporting this bug!

(In reply to comment #8)

Size of a picture: not in pixels, but for example in millimeters at printing and at the display: not the resolution, but the density: pixel/length. For example, I inserted a 600 dpi picture, but Writer regarded this 120 dpi, because of my monitor setting is 120 dpi. The resolution remained, but the size in millimeters/inches/etc expanded to 5 times.

Example for data loss: if you create this document on an another computer, on where the display resolution is 96 dpi, the picture will be larger, but you maked the same steps. I do not know if Writer stores the resolution of the pictures. If do not, close this document, and open at an another computer with different display settings: the size of the picture varies. The same document looks different on 2 computers. The resolution always remains, but the enlargement varies (the resolution density, pixel/length). For examle, a picture is 2 line height on one computer, and 3 line height on another one.

Why is this unconfirmed still?

(In reply to comment #10)
> Why is this unconfirmed still?

Because probably nobody understood what is the problem.
For example, if I look at the three files provided by flamingdescent, I see the same thing. But probably he changed only the size of the screen, not its resolution. 

Could you attach two "identical" documents, one made on a computer with 120 dpi screen resolution and one made on a computer with 96 screen resolution?

Best regards. JBF

(In reply to comment #11)

Pixel density (in unit pixel/inch) is stored in the .jpg file. Writer ignores this, and uses the display settings. If you insert the same file with 2 computers with different display pixel density, you will get different result in the .odt file. Reproduction: insert a .jpg file to a document, view the size in the document in inches or millimeters, save, exit from LibreOffice. View the actual display density in Windows (Control Panel, Resolution special settings). Modify it. 963 dpi is the default, for example, use 120 dpi or 144 dpi. Restart Windows. Insert the same .jpg file to a new document. The size of the picture in inches or in millimeters will be different.

Another example: the pixel density of a .jpg file is 600 pixel/inch. Insert this to a document, and view the size in the document: if the setting is original size, Writer uses 96 or 120 or 144 dpi: the picture is 5 times bigger.

Please, don't set to new a bug report you created yourself.
I understand your explanations. I just need to see an example.
And what about PNG files?

Best regards. JBF

(In reply to comment #13)
> I just need to see an example.
See the attachment https://bugs.freedesktop.org/attachment.cgi?id=64820
> And what about PNG files?
I do not have any png files, so I did not test it.

(In reply to comment #14)
> (In reply to comment #13)
> > I just need to see an example.
> See the attachment https://bugs.freedesktop.org/attachment.cgi?id=64820

No, an example of 2 documents like asked in comment https://bugs.freedesktop.org/show_bug.cgi?id=52598#c11

> > And what about PNG files?
> I do not have any png files, so I did not test it.

It's unfortunate because PNG is the preferred image format for LibreOffice.

Best regards. JBF

Created attachment 89344 [details]
Writer used 120 pixel/inch, but this picture has 600 pixel/inch, the display has 144 pixel/inch

I inserted the .jpg file in the previous attachment to an empty document. The pixel density of the .jpg file is 600 pixel/inch, but Writer used 120 pixel/inch. The display pixel density setting is 144 pixel/inch at me. (Writer inserted the picture in 28% size, this is not a bug, because the picture is reduced to the width of the line.)

Sorry, there was 120 dpi the display resolution when I observed this error. Writer uses always 120 dpi at inserting .jpg files, and ignores the pixel density stored in the .jpg file (600 dpi in the attachment, so Writer uses 5 times enlargement at this file). The display density is no object, I tried this with 144 and 96 pixel/inch setting. The error is not happen at inserting .png files, I tried to insert 96 and 600 dpi files (at 96 pixel/inch display setting). But the attachment converted to .png with GIMP is 5-times bigger (9 times with Paint instead of GIMP), so it is better to use .jpg files.

Not sure if it is a bug. LibreOffice and before OOo did that since the beginning.
From the point of view of text processor, you should prefer to define the size of the image in the page, not in pixels but in cm. 
Not sure too if the pixel/inch is a portable measure from paper to screen or another support. Indeed each support has its own pixel size.

Set status back to unconfirmed.

Best regards. JBF

(In reply to comment #9)
> ... I inserted a 600 dpi picture, but Writer regarded this 120 dpi,
> because of my monitor setting is 120 dpi. The resolution remained, but the
> size in millimeters/inches/etc expanded to 5 times.

From attachment 64820 [details]:

$ identify -verbose Vegyeskép.jpg | head -n7
Image: Vegyeskép.jpg
  Format: JPEG (Joint Photographic Experts Group JFIF format)
  Class: DirectClass
  Geometry: 3200x1688+0+0
  Resolution: 600x600
  Print size: 5.33333x2.81333
  Units: PixelsPerInch

When I insert this image into a Writer document with a suitably large page size the resultant image is 26.67" wide. 3200 divided by 26.67 = ~120, which is the indicated DPI reported in this bug rather than the 600 DPI stored in the JPEG. If the DPI stored in the JPEG were being respected the image would be inserted at the indicated 5.33333x2.81333 inches.

The only part of the quoted statement I am concerned about is this:

> because of my monitor setting is 120 dpi

The laptop I tested this on appears to have a 100ppi LCD screen (13 9/16 inches wide @ 1366 pixels), so I am not certain the DPI is being derived from the screen. It may be set in the JPEG import filter. Anyway, confirmed under GNU/Linux x86_64 using v4.2.5.2. Status set to NEW. Platform set to All/All.

It may be that this is not a bug that can be fixed, but we should at least get a developer to look at this. Summary amended to point to comment 19, which contains steps to reproduce.

Created attachment 116705 [details]
example image

I ran into the same problem. I prepared some pictures with Photoshop Elements, and wanted to insert them "as is" in a Writer document, but I wasn't able to do so.

When you edit an image in Photoshop, the properties of the image will show the number of pixels (obviously) and the desired DPI setting. The two combined can be used to calculated the desired size of the image in cm or inches. 

Writer ignores the desired DPI setting and will always resample the image based on the DPI setting of the screen (96 DPI in my case) and the size of the image in the document.

With Compress Graphic you can change the DPI setting of the image, but that seems to be not of the orginal image but of the the already resampled image. 

To makes this clear, the following example. I have an image of 1600 x 1065 pixels. When I insert this image on a A4 page, it will be resampled to fit the width of the page using a resolution of 96 DPI. The resulting image has a size of 642 x 427 pixels.

When I open Compress Graphic I can change the DPI setting back to the original 300 DPI, but then I will get an image size of 2007 x 1335 pixels, so a resampling of the already resampled image will take place. That is not good for the quality of the image, any resampling should be done based on the original image.

In Photoshop Elements there is a setting that allows you to switch resampling on or off. If you switch it off changing the DPI setting is the only way to change the size of the image in cm or inches. With resampling on you can choose any DPI and size in cm or inch. 

So in my opinion three things should happen:
1. Writer should use the desired DPI setting of the image if the DPI setting is in the properties of the image (and if possible).
2. If Writer needs to resample an image, it should always use the original image.
3. It should be possible to switch resampling off, and just use the DPI setting to get the desired size in cm or inches. 

Attached are an example image, and two screen dumps of the Photoshop window, one with resampling enabled, and one without.

Created attachment 116706 [details]
Photoshop resize window - resampling off

Created attachment 116707 [details]
Photshop resize windows - resampling on

The problem is really very simple. JPEG file headers contain information about the size of the picture, measured in pixels. They also contain information about the dpi setting. The dpi setting is used to calculate the desired picture size in cm or inch, it doesn't do anything else. A high dpi setting will result in a small high resolution picture, a low dpi setting in a large low resolution picture. The dpi setting has nothing to do with the actual contents of the picture, so changing the dpi setting doesn't do anything with this contents. It is very important to keep this in mind.

The problem is that LibreOffice doesn't understand the JPEG headers of at least Photoshop elements. It will not read the dpi setting, instead Libreoffice will use the dpi setting of the display. So a JPEG photo that is intended to be 10cm x 10cm with 300 dpi, will become 31.25cm x 31.25cm in Writer, because I have a 96dpi display. (300/96 x 10 = 31.25)

Libreoffice does understand the JPEG headers of (for instance) Microsoft Paint. If I open a JPEG picture made by Photoshop Elements in Paint, and immediately save it again, that picture will be opened correctly by Libreoffice. However, Paint uses a lower quality compression setting, so the actual contents is changed. Mind you, not the size in pixels, or the dpi setting!!

It is indeed a serious problem, because it prevents people from making high quality documents, high quality meaning high resolution images for printing etc. It can't be very difficult to solve I guess, it just needs someone who knows about these headers, and can find a fool-proof way to handle them

It is a problem with handling the EXIF headers. The EXIF headers contain information about dpi etc., and LibreOffice doesn't handle them properly. It is a really serious problem if you want to create high quality documents with high resolution pictures. So I'm going to raise the importance to major.

*** Bug 103273 has been marked as a duplicate of this bug. ***

In a previous comment I stated that the information is in the EXIF headers, this is a mistake, the information is in the standard JPEG headers. 

I've uploaded two IrFanView information headers. The difference between the two is the dpi setting in the header, nothing else. That information is used to calculate the print size in cm / inch. It seems that Writer isn't (always) capable to read the dpi setting from the header, and it then replaces the dpi setting by the dpi of the screen. This results in a completely wrong size of the picture in the Writer document. Adjusting the size in Writer results in resampling the picture, and using the wrong, mostly lower, dpi setting.

It's very simple, anyone who is able to understand the way jpg and other graphic files are handled in Writer, can understand this,

Please fix this problem!!

Created attachment 137701 [details]
JPG header information with low-res dpi setting

Created attachment 137702 [details]
JPG header information with high-res dpi setting

*** Bug 115287 has been marked as a duplicate of this bug. ***

The problem still exists, the headers of certain images are still not handled properly. Very annoying.

*** Bug 132658 has been marked as a duplicate of this bug. ***

Duplicated bug had a title " ENHANCEMENT: Image without resolution set should get a default fallback resolution (not based on a screen resolution)".
I agree that this is annoying, and with bug 96178 (and bug 144070 which is the same issue) should be of High priority. 
Because although it's not common, when it happens it is not obvious, and creates duplicates.

I set High because there are duplicates and bug 96178 and probably others like bug 119492.

The original problem has been resolved, Writer handles the dpi setting properly. That means that I can now prepare images with photo editing software, and just enter them in a Writer document.

Writer is not meant to be photo editing software, so don't expect it to do that.

Images do not have dimensions in cm or inch. Images exist out of pixels, and those are dimensionless. It is the dpi setting that will software at which size the image has to be printed. Unfortunately high resolution jpg images from cameras often have a rather silly 72 dpi as standard setting, which means that printed images would be ridiculously big. The only proper way to prepare those images for use in a Writer document is with photo editing software. The same applies to images without a dpi setting. Load these images in photo editing software, set the proper dpi setting and required image size, and recalculate the number of pixels. 

I use Affinty Photo for that purpose. It is an excellent program, cheap, and has free updates.

We're talking about a jpg file not a TIFF file using jpeg compression=>removing block on "Images-TIFF"

Dear Zoltán Hegedüs,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug