[Solved] Image Sizing Issues with Adobe PSE 15+ JPEG Format

[doktoroblivion]

I am actually not sure this is a product issue, but I never recall having this issue before 4.1.5 so perhaps something has happened.
I am currently using OOffice 4.1.5 Writer and importing images, but Writer appears to be telling me something different from what
Adobe and Windows is telling me and then scaling based on that information I believe incorrectly. I will try and demonstrate what
I mean with a series of screenshots for each application handling the image.

1. First Adobe PSE 15, edits the images and appears to show the image at the correct size, though zoomed out (based on my screen res)

Adobe PSE Showing Edit window dimensions and information

2. Next I use Windows' Explorer to check the image size and its dimensions

Windows Explorer Dialog showing image dimensions, etc...

OOo_ImageIssue_WindowsPropertyOfFile_skaliert.jpg (79.89 KiB) Viewed 5124 times

Both of the above look correct to me and agree with my expectations, even if I print it out from explorer..!

3. Lastly in OO Writer, I import the file as an image and expect the image dialog to show same dimensions, it does not.

OpenOffice 4.1.5 Image dialog with dimensions in inches

The reason for writing this issue is I have had major issues with OO Writer rescaling things when sub documents are brought into a main
document and the images are not the exact dimensions they are supposed to be. I don't really care about that problem any more as long
as there is some way on fixing the above. Any ideas? I have checked some old documents where this still works, which I have not touched
either by the way, and from what I can tell only Image Size in inches at the bottom always matches the Original Size in inches to the right
in the above dialog.

[John_Ha]

It doesn't matter what Writer is saying about the image as that is metadata about the image and may be incorrect. What is important is the pixel count when you bring in the image. Writer does not change the pixel count though if you incorrectly paste a JPG image, Writer will convert it to a PNG image. You can change the image size inside AOO by dragging the image handles but this does affect the metadata.

I have never had images change size when brought into a master document in 4.1.5. If you have please upload a file showing the problem and a detailed description of what you expect to happen, and what actually does happen. Your expectation may be wrong.

See [Tutorial] Some useful hints on using images for a discussion on how best to handle images in Writer. See Chapter 8 - Working with Graphics in the Writer Guide.

Showing that a problem has been solved helps others searching so, if your problem is now solved, please view your first post in this thread and click the Edit button (top right in the post) and add [Solved] in front of the subject.

[Bill]

In the screen shots, Adobe and Windows Explorer are showing the size of an image printed at 300 dpi. The "Original Size" shown on the AOO Picture dialog is the size that would be displayed at full scale on a monitor at 96 ppi. Writer will display the image at the "Original Size" if it will fit. In this case, the image has been scaled back to fit in the 6.93" width of the text area of the page.

[doktoroblivion]

Thank you Bill and John for your reply, but perhaps I am asking the wrong questions.

What is at issue here is past behavior that appears to me to be different from OOWrite 4.1.1. As I have already explained above I believe the issue here is OOWriter's sizing of the image based on ppi and pixel width and heigth. When I do the computation I get the proper sizes that I want in inches for both width and height using the simple caculation of pixel_width or pixel_height divided by ppi (pixels per inch). That is how its supposed to work based on all the documentation I have read (e.g.: https://helpx.adobe.com/photoshop-eleme ... resolution). Having said this before I show Microsoft Paint below and Adobe PE15 dimensions:

Now I show the OOWriter after the image was imported. My questions are:
- why does the application apparently display the image size properties incorrectly?
- why does the application import the resize the image to the full width of the document, when based on calculations it should only be 5.1 inches in width? To be honest, this is the issue that annoys me the most..!

Again, based on documentation that I have read and having used OOWriter and Adobe Photoshop in the past for decades, what am I missing here? Its probably something really stupid, but to me Writer is not behaving itself correctly, but it could be just me, please explain.

Kind regards,
Erick

[RoryOF]

Change your OpenOffice picture scaling to 32% and all should be well. 32% is 96/300 (x 100 for %).

Why does it do it? It is a different application and works in a different way.

[John_Ha]

Please

1. Upload an image which causes you a problem, and
2. explain precisely what you do to insert it, and
3. explain what you think should happen, and
4. explain what actually happens.

The maximum file size here is 128kB so if the image is larger, either blank out most of it to reduce the file size or reduce the colour depth; or use a file share site. See [Tutorial] Some useful hints on using images for image manipulation.

[doktoroblivion]

@John_Ha,

I have uploaded a test photo that is, according to Adobe PE15, 930x620 at 300ppi and therefore should be 3.1x2.067 inches. I have placed that image inline here:

Per your questions:
1. Upload an image which causes you a problem, and - DONE
2. explain precisely what you do to insert it, and - Menubar > Import > Image > From File, select image to import
3. explain what you think should happen, and - the image should come into ANY new document at 3.1x2.067 images at 100%
4. explain what actually happens. - the image is scaled to page width and its properties appear wrong to me

Thanks in advance for your help..!
Erick

[RoryOF]

If you change the scaling factor in Writer to 32% you will get the correct size in Writer.

(9.69 x 32)/100 = 3.10

QED.

[doktoroblivion]

Hi RoryOF, I find no general property to set the default scaling factor for images at 32 percent, neither in the OO General nor the OOWriter properties. Would you care to share what menubar, etc., steps I ought to be using? If you are implying that I scale each image, that's unacceptable. Is this a HACK, or is it in the documentation somewhere? The documentation I have found does not say much (e.g. https://wiki.openoffice.org/wiki/Docume ... ter/Insert), do you have a better link that explains how-to do this?

test.zip

(67.92 KiB) Downloaded 121 times

[John_Ha]

Please zip your image file and upload it as a file, and not as an in-line image; or upload it to a file share site.

I need to see your file's metadata but if I copy the in-line image and save it, I set the metadata.

[doktoroblivion]

I have updated the append above. I would also like to add following the link in your footer above I downloaded and read through the section in the doc on images. It says this

Original size button: when clicked, restores the image to its original size.

The button in the images I have provided to me does not show the correct size, given ppi and image width and height. It does for other images that I had scaled in the past using Adobe PE 10, so now I am beginning to wonder if PE15 changed the way it stores image data that OOWriter is no longer works well with. Just a thought.

[Bill]

Writer uses 96PPI to calculate an "Original Size" for images. LO Writer has even modified the Image dialog to show "(96PPI)" next to the "Original Size". AFAIK, the resolution setting from the JPEG file which is used by graphics editors has never been used by Writer.

Here is a 6-year old bug report for LO Writer. I haven't found one for AOO Writer.

Bug 52598 - Writer ignores original picture pixel density in .jpg files

[John_Ha]

Writer uses 96PPI to calculate an "Original Size" for images.

I don't think that can always be true as it is certainly wrong for me. That being said I am somewhat confused and need to do more analysis.

I cropped a 300dpi JPG file from my camera to 600 x 300 pixels and saved it while allowing the EXIF data to be changed. The EXIF data still showed it was 300 dpi but for some reason the EXIF data later disappeared from the JPG file (when viewed in IrfanView). Note that when you save a JPG file you have the option of retaining the original EXIF data or of changing it to reflect the current values.

IrfanView shows a Print Size as 2.0 inches wide which is correct based on the dpi. It appears that IrfanView calculates the Print Size from the dpi value and pixel count though it may be reading it.

I then saved the image as a BMP and also as a PNG. Neither BMP nor PNG files store EXIF data (it's for photos) but they do store other metadata. BMP, for example, stores Image_Width, Image_Height, X_pixels_per_metre and Y_pixels_per_metre.

Edit: It appears that PNG files can store EXIF data as an attribute.

Image information for the BMP file as shown in IrfanView

I then dragged all three images into Writer. I got identical results when I went Insert > picture > From file.

The image widths on the page were 50.8mm which is equal to 2.0 inches.

So, with small images which fit between the margins, Writer is either reading the 300dpi value, or is reading the Print Size or Image width value.

Images larger than the page width are scaled down to fit.

More analysis is required ...

[John_Ha]

This is what the .odt file looks like. The images are 2 inches (50.8mm) wide as expected from the 300 dpi value.

.odt file with 300 dpi images

I then used IrfanView to edit the dpi value and change it to 150dpi. IrfanView now showed the width as 4 inches, which is correct. When I inserted the image into Writer it was now 4 inches (100.8mm) wide.

I then created an image twice as wide (8 inches, 1200 pixels at 150 dpi) which was too wide for the page margins. Writer then scaled the image to fit between the margins.

So Writer definitely seems to be reading the dpi value and the pixel count, and then calculating the image size on the page using width = pixel_count/dpi.

So, according to my tests:

When you insert an image (JPG, PNG and BMP were tested) Writer reads the dpi value and pixel count in the image file and calculates the image width as image_width = pixel_count / dpi. Writer inserts the image with the calculated width.
If the calculated width is greater than the distance between the page margins Writer scales the image to fit between the margins.

[John_Ha]

But ...

... doktoroblivion's OOo_ImageIssue_AdobePSE15_TestResult_skaliert.jpg is 930 x 680 pixels and 300 dpi. I would therefore expect it to insert at 3.1 inches wide. It doesn't - it stretches between the page margins. If I increase the page margins it inserts at 246mm wide or 9.68 inches. 930 / 9.68 inches is 96 dpi.

I used IrfanView for the following tests.

If I now save OOo_ImageIssue_AdobePSE15_TestResult_skaliert.jpg as a BMP it inserts at the correct 3.1 inches wide.

I then changed the dpi value in OOo_ImageIssue_AdobePSE15_TestResult_skaliert.jpg to 150 dpi, then changed it back to 300dpi without making any other changes. This merely rewrote the dpi value. The file now inserted at the correct 3.1 inch width.

I then cropped OOo_ImageIssue_AdobePSE15_TestResult_skaliert.jpg so it was half as high and saved it. It now inserted at the correct width.

I then did a tiny edit to OOo_ImageIssue_AdobePSE15_TestResult_skaliert.jpg and saved it with IrfanView. It then inserted at the correct width.

So I am 99.99% certain there is something faulty in the metadata in doktoroblivion's original OOo_ImageIssue_AdobePSE15_TestResult_skaliert.jpg file which is causing AOO to read something wrongly or not to read it. Presumably when AOO cannot read the dpi data, AOO then defaults to 96dpi.

I would suggest doktoroblivion stops using his Adobe PSE 15 image editor and uses IrfanView instead as I suspect Adobe PSE 15 is causing the problem.

I then went to Get Metadata and checked the original file, which inserted at 96dpi; and the IrfanView saved file, which inserted at 300 dpi. The site gave slightly different results for the two files' metadata but both showed 300 dpi so I don't know where the error is coming from.

[John_Ha]

I have now saved OOo_ImageIssue_AdobePSE15_TestResult_skaliert.jpg with paint.net and with GIMP. In both cases the file then inserted in Writer at the correct size.

The problem therefore lies with the file created by Adobe PSE 15.

Showing that a problem has been solved helps others searching so, if your problem is now solved, please view your first post in this thread and click the Edit button (top right in the post) and add [Solved] in front of the subject.

[doktoroblivion]

John, this is what I suspected though could not prove.

The last bit of information I will leave this append with is the XMP image data that is displayed when viewing the metadata using PSE 15's tooling, see below. Not sure you can glean anything extra from other than the tiff tags look a bit ackward to me for a jpeg file, but I am not an image expert by any stretch. Do you know if OpenOffice or other applications expect different metadata xml tags?

Also, here is the raw xml data straight from APSE15:

Code: Select all

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.6-c123 79.158978, 2016/02/13-01:11:19        ">
   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      <rdf:Description rdf:about=""
            xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/"
            xmlns:stEvt="http://ns.adobe.com/xap/1.0/sType/ResourceEvent#"
            xmlns:dc="http://purl.org/dc/elements/1.1/"
            xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/"
            xmlns:xmp="http://ns.adobe.com/xap/1.0/"
            xmlns:tiff="http://ns.adobe.com/tiff/1.0/"
            xmlns:exif="http://ns.adobe.com/exif/1.0/">
         <xmpMM:DocumentID>adobe:docid:photoshop:483406fd-06da-11e9-ab56-b888f81cb96a</xmpMM:DocumentID>
         <xmpMM:InstanceID>xmp.iid:ef2668fe-794a-264b-b6f6-9f3f28a5dc38</xmpMM:InstanceID>
         <xmpMM:OriginalDocumentID>A8896991A7AF48221E1B52E37FD9A91C</xmpMM:OriginalDocumentID>
         <xmpMM:History>
            <rdf:Seq>
               <rdf:li rdf:parseType="Resource">
                  <stEvt:action>saved</stEvt:action>
                  <stEvt:instanceID>xmp.iid:530ec8ba-6e1e-2e4f-8394-15708ca4d164</stEvt:instanceID>
                  <stEvt:when>2018-12-23T12:43:47-05:00</stEvt:when>
                  <stEvt:softwareAgent>Adobe Photoshop Elements 15.0 (Windows)</stEvt:softwareAgent>
                  <stEvt:changed>/</stEvt:changed>
               </rdf:li>
               <rdf:li rdf:parseType="Resource">
                  <stEvt:action>saved</stEvt:action>
                  <stEvt:instanceID>xmp.iid:ef2668fe-794a-264b-b6f6-9f3f28a5dc38</stEvt:instanceID>
                  <stEvt:when>2018-12-23T14:29:18-05:00</stEvt:when>
                  <stEvt:softwareAgent>Adobe Photoshop CC 2021 (Windows)</stEvt:softwareAgent>
                  <stEvt:changed>/</stEvt:changed>
               </rdf:li>
            </rdf:Seq>
         </xmpMM:History>
         <dc:format>image/jpeg</dc:format>
         <photoshop:LegacyIPTCDigest>27AE215A8725B449ECD8C3F4D1BB6BAC</photoshop:LegacyIPTCDigest>
         <photoshop:ColorMode>3</photoshop:ColorMode>
         <photoshop:ICCProfile>sRGB IEC61966-2.1</photoshop:ICCProfile>
         <xmp:CreateDate>2018-12-23T12:43:26-05:00</xmp:CreateDate>
         <xmp:ModifyDate>2018-12-23T14:29:18-05:00</xmp:ModifyDate>
         <xmp:MetadataDate>2018-12-23T14:29:18-05:00</xmp:MetadataDate>
         <xmp:CreatorTool>Adobe Photoshop Elements 15.0 (Windows)</xmp:CreatorTool>
         <tiff:ImageWidth>1009</tiff:ImageWidth>
         <tiff:ImageLength>738</tiff:ImageLength>
         <tiff:BitsPerSample>
            <rdf:Seq>
               <rdf:li>8</rdf:li>
               <rdf:li>8</rdf:li>
               <rdf:li>8</rdf:li>
            </rdf:Seq>
         </tiff:BitsPerSample>
         <tiff:PhotometricInterpretation>2</tiff:PhotometricInterpretation>
         <tiff:Orientation>1</tiff:Orientation>
         <tiff:SamplesPerPixel>3</tiff:SamplesPerPixel>
         <tiff:XResolution>3000000/10000</tiff:XResolution>
         <tiff:YResolution>3000000/10000</tiff:YResolution>
         <tiff:ResolutionUnit>2</tiff:ResolutionUnit>
         <exif:ExifVersion>0221</exif:ExifVersion>
         <exif:ColorSpace>1</exif:ColorSpace>
         <exif:PixelXDimension>930</exif:PixelXDimension>
         <exif:PixelYDimension>680</exif:PixelYDimension>
      </rdf:Description>
   </rdf:RDF>
</x:xmpmeta>

Thank you for all your effort on this. I am going to contact Adobe Support and ask them exactly what is going on here, since I expect the product to perform and behave properly, that's why I purchased it..!
Again, thanks a bunch and Happy Holiday!

[John_Ha]

It would be worth doing some investigation by finding utilities or web sites which can read the metadata so you can point out exactly what the problem is.

I ask because I don't know why IrfanView, paint.net, GIMP and the web site I used all show 300 dpi. If they show 300 dpi why doesn't AOO see and use the 300 dpi value?

LO does the same as AOO.

[John_Ha]

See the LO bug report. Don't believe everything in the report but Comment 26 is interesting as it says that LO reads Paint metadata OK but does not read Photoshop metadata OK. That is what is happening here.

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!!

I wonder if the JPG file format changed and AOO and LO do not understand the new structure? But I then find that JPG metadata is read by a common library libjpg used by everyone.

I remain somewhat confused.

[doktoroblivion]

John,
MS Paint seems to read the image correctly and then when I re-save it and then pull if back into APSE15 I see this xml data, I have not done a line by line compare, but it appears the same to me.

Code: Select all

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.6-c123 79.158978, 2016/02/13-01:11:19        ">
   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      <rdf:Description rdf:about=""
            xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/"
            xmlns:stEvt="http://ns.adobe.com/xap/1.0/sType/ResourceEvent#"
            xmlns:dc="http://purl.org/dc/elements/1.1/"
            xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/"
            xmlns:xmp="http://ns.adobe.com/xap/1.0/"
            xmlns:tiff="http://ns.adobe.com/tiff/1.0/"
            xmlns:exif="http://ns.adobe.com/exif/1.0/">
         <xmpMM:DocumentID>adobe:docid:photoshop:483406fd-06da-11e9-ab56-b888f81cb96a</xmpMM:DocumentID>
         <xmpMM:InstanceID>xmp.iid:ef2668fe-794a-264b-b6f6-9f3f28a5dc38</xmpMM:InstanceID>
         <xmpMM:OriginalDocumentID>A8896991A7AF48221E1B52E37FD9A91C</xmpMM:OriginalDocumentID>
         <xmpMM:History>
            <rdf:Seq>
               <rdf:li rdf:parseType="Resource">
                  <stEvt:action>saved</stEvt:action>
                  <stEvt:instanceID>xmp.iid:530ec8ba-6e1e-2e4f-8394-15708ca4d164</stEvt:instanceID>
                  <stEvt:when>2018-12-23T12:43:47-05:00</stEvt:when>
                  <stEvt:softwareAgent>Adobe Photoshop Elements 15.0 (Windows)</stEvt:softwareAgent>
                  <stEvt:changed>/</stEvt:changed>
               </rdf:li>
               <rdf:li rdf:parseType="Resource">
                  <stEvt:action>saved</stEvt:action>
                  <stEvt:instanceID>xmp.iid:ef2668fe-794a-264b-b6f6-9f3f28a5dc38</stEvt:instanceID>
                  <stEvt:when>2018-12-23T14:29:18-05:00</stEvt:when>
                  <stEvt:softwareAgent>Adobe Photoshop CC 2021 (Windows)</stEvt:softwareAgent>
                  <stEvt:changed>/</stEvt:changed>
               </rdf:li>
            </rdf:Seq>
         </xmpMM:History>
         <dc:format>image/jpeg</dc:format>
         <photoshop:LegacyIPTCDigest>27AE215A8725B449ECD8C3F4D1BB6BAC</photoshop:LegacyIPTCDigest>
         <photoshop:ColorMode>3</photoshop:ColorMode>
         <photoshop:ICCProfile>sRGB IEC61966-2.1</photoshop:ICCProfile>
         <xmp:CreateDate>2018-12-23T12:43:26-05:00</xmp:CreateDate>
         <xmp:ModifyDate>2018-12-23T14:29:18-05:00</xmp:ModifyDate>
         <xmp:MetadataDate>2018-12-23T14:29:18-05:00</xmp:MetadataDate>
         <xmp:CreatorTool>Adobe Photoshop Elements 15.0 (Windows)</xmp:CreatorTool>
         <tiff:ImageWidth>1009</tiff:ImageWidth>
         <tiff:ImageLength>738</tiff:ImageLength>
         <tiff:BitsPerSample>
            <rdf:Seq>
               <rdf:li>8</rdf:li>
               <rdf:li>8</rdf:li>
               <rdf:li>8</rdf:li>
            </rdf:Seq>
         </tiff:BitsPerSample>
         <tiff:PhotometricInterpretation>2</tiff:PhotometricInterpretation>
         <tiff:Orientation>1</tiff:Orientation>
         <tiff:SamplesPerPixel>3</tiff:SamplesPerPixel>
         <tiff:XResolution>3000000/10000</tiff:XResolution>
         <tiff:YResolution>3000000/10000</tiff:YResolution>
         <tiff:ResolutionUnit>2</tiff:ResolutionUnit>
         <exif:ExifVersion>0221</exif:ExifVersion>
         <exif:ColorSpace>1</exif:ColorSpace>
         <exif:PixelXDimension>930</exif:PixelXDimension>
         <exif:PixelYDimension>680</exif:PixelYDimension>
      </rdf:Description>
   </rdf:RDF>
</x:xmpmeta>

As you have already alluded, re-saving in paint then re-importing into AOO 4.1.5 works fine! So, its some metadata issue somewhere. I have also found this

The Exif tag structure is borrowed from TIFF files. On several image specific properties, there is a large overlap between the tags defined in the TIFF, Exif, TIFF/EP, and DCF standards. For descriptive metadata, there is an overlap between Exif, IPTC Information Interchange Model and XMP info, which also can be embedded in a JPEG file. The Metadata Working Group has guidelines on mapping tags between these standards.[4]

When Exif is employed for JPEG files, the Exif data are stored in one of JPEG's defined utility Application Segments, the APP1 (segment marker 0xFFE1), which in effect holds an entire TIFF file within. When Exif is employed in TIFF files (also when used as "an embedded TIFF file" mentioned earlier), the TIFF Private Tag 0x8769 defines a sub-Image File Directory (IFD) that holds the Exif specified TIFF Tags. In addition, Exif also defines a Global Positioning System sub-IFD using the TIFF Private Tag 0x8825, holding location information, and an "Interoperability IFD" specified within the Exif sub-IFD, using the Exif tag 0xA005.

Formats specified in Exif standard are defined as folder structures that are based on Exif-JPEG and recording formats for memory. When these formats are used as Exif/DCF files together with the DCF specification (for better interoperability among devices of different types), their scope shall cover devices, recording media, and application software that handle them.

Exif Version 2.21 (with Adobe RGB support) is dated 11 July 2003

[doktoroblivion]

I can confirm that when Adobe PSE15 scales and subsequently saves a scaled image it fundamentally changes the color space to the following which must be the root of the issue. Whether I choose to convert this into the built-in GIMP 2.0 sRGB or maintain it, GIMP will save this into an acceptable RGB format for AOO.

Code: Select all

sRGB IEC61966-2.1
IEC 61966-2.1 Default RGB colour space - sRGB
Hersteller: IEC http://www.iec.ch
Copyright: Copyright (c) 1998 Hewlett-Packard Company

I can also update that if I turn OFF color management, I still have the same issue without the popup in GIMP telling me to convert, so its something else.

[John_Ha]

I can confirm that when Adobe PSE15 scales and subsequently saves a scaled image it fundamentally changes the color space to the following which must be the root of the issue.

I don't think that can be the problem because colour space is to do with how many colours there are in the image. We have a problem with dpi and/or image size.

If an image is scaled (ie resampled) to a different size new colours will be created by the mixing or interpolation of adjacent pixels and the colour space will change.

A thought. Open my test JPG file in Adobe PSE, do a trivial edit, and save it. Does it now work OK?

Also, open your "bad" jpg file with Adobe PSE and save it as a PNG. Does the PNG work OK?

Now open the PNG and save it a JPG. Does the JPG now work OK?

[doktoroblivion]

John,
okay, I downloaded your 600x300 images and rescaled the jpeg from 300ppi to 200ppi, which meant the image went from 600x300 to 400x200, so my expectations would be that it should size in AOO as a 2inch by 1 inch image, right? But after the resampling and saving by APSE15 and subsequent import into AOO I get some strange size closer to 4+ inches wide by 2+ inches high.

I have attached the image in a zip here. I will run a test storing into a PNG next and update this append with the result.


Okay, I can confirm that PNG functions the way I would expect rescale to work. When I perform the same rescale operation from 300 to 200 ppi the PNG imported into AOO scales correctly and its properties match my expectations, so it appears JPEG resampling is only affected.

Okay, I can confirm taking the PNG image and saving it as JPEG brings the issue back or at least provided no work-around to the issue.

So, to answer your questions:
A thought. Open my test JPG file in Adobe PSE, do a trivial edit, and save it. Does it now work OK? NO

Also, open your "bad" jpg file with Adobe PSE and save it as a PNG. Does the PNG work OK? YES

Now open the PNG and save it a JPG. Does the JPG now work OK? NO

[John_Ha]

I think we have identified the cause of the problem as:

1. When Adobe Photoshop Elements 15 saves an image as a JPG file, the JPG metadata (300 dpi, pixel count) appears to be saved correctly but the metadata is not read by AOO or LO so the image is sized incorrectly.

2. If I open the JPG image file with another image editor (GIMP, paint.net and IrfanView were tested) and save it as a JPG with a new name, the metadata appears to be the same (300 dpi, pixel count) but the metadata is now read correctly by AOO and LO and the image is sized correctly.

3. When Adobe Photoshop Elements 15 saves an image as a PNG or other format, AOO and LO read the metadata correctly.

Conclusion: When Adobe Photoshop Elements 15 saves an image as a JPG file there is something unusual about the metadata which means AOO and LO cannot read it.

It would be very useful if someone using MS Word could test inserting OOo_ImageIssue_AdobePSE15_TestResult_skaliert.jpg from your ZIP file. Does it insert as 5.1 inches (1531 / 300) wide, which it should do? Or a different width?

Showing that a problem has been solved helps others searching so, if your problem is now solved, please view your first post in this thread and click the Edit button (top right in the post) and add [Solved] in front of the subject.

[John_Ha]

I think I have identified and corrected the error in the Adobe Photoshop Elements saved JPG file. It appears the first few bytes of the header are incorrect.

I used a binary editor (HxD) to examine the first bytes of the JPG saved by Adobe Photoshop elements. They are shown below.

I then examined the first bytes of any good JPG file as saved by IrfanView, including the ADobe file as saved with IrfanView. The files as saved with IrfanView is shown below.

I therefore copied everything highlighted up to EXIF from the good JPG file. I deleted everything highlighted up to EXIF in the Photoshop saved JPG file and replaced it by what I had copied.

The corrected file now inserts at the correct size into AOO and LO. The headers in Hex and text are:

Code: Select all

FF D8 FF E1 18 4F 45 78 69 66 >>> ÿØÿá.OExif

FF D8 FF E0 00 10 4A 46 49 46 00 01 01 01 01 2C
01 2C 00 00 FF E1 18 4F 45 78 69 66 >>> ÿØÿà..JFIF.....,.,..ÿá.OExif

HxD Edited image.zip

JPG file edited with HxD to correct faulty header

(68.14 KiB) Downloaded 111 times

Showing that a problem has been solved helps others searching so, if your problem is now solved, please view your first post in this thread and click the Edit button (top right in the post) and add [Solved] in front of the subject.

[Bill]

Writer seems to be using the old JFIF standard which Adobe says is obsolete and not compatible with EXIF. Adobe uses the EXIF standard only. Using exiftool to extract the metadata in groups shows that the files which are correctly sized by Writer include a JFIF group containing resolution data. The files from Photoshop Elements don't have the JFIF group.

If I use exiftool to change the JFIF resolution but not the EXIF resolution for a .jpg that is displayed with the correct size, then Writer uses the new JFIF resolution and the image size changes. If I completely remove the JFIF settings then Writer uses 96ppi on my system and again the image size changes. In both cases, Writer ignores the EXIF resolution settings stored in the file.

JPEG File Interchange Format

Here are comments from Adobe in 2010:
Photoshop CS5 jpegs being resampled on import to another program?

[doktoroblivion]

I confirm your results by importing the image from the zip file. The problem is, should we be changing the image to fit AOO/LO behavior or should it be adopting the new format? Was this change made by Adobe a result of adopting a new standard that AOO/LO has to now make updates to support? Do you think its appropriate for me to go back to Adobe and complain about the standards issue with missing JFIF support?

Would the solution be for AOO/LO to put toleration code in, as it appears Microsoft has by using an obsolete standard, to detect whether or not sufficient JFIF exists and use it if it does, otherwise use the EXIF data it present?

[John_Ha]

Would the solution be for AOO/LO to put toleration code in...

I would not hope for a quick solution even if you raise it as a bug as it is an annoyance rather than something more important like a data loss problem.

You see when it happens so you know it has happened. The fix is very simple - merely resize the image to the size you want it to be.

[doktoroblivion]

This is a known issue with AOO 4.0/4.1 (all mods) and is currently documented here in bugzilla: https://bz.apache.org/ooo/show_bug.cgi?id=127971

One can workaround this issue in one of the following ways:

• - In AOO/LO use a frame or table to size the image to your desired dimensions
  - In AOO/LO once imported, resize the image to the dimensions you want by using right-click -> Image -> scaling
  - If adjustments within AOO/LO document are not to your liking, export the image in Adobe PSE 15 using PNG format, though it is more difficult to control the resultant image's size
  - Continue to use Adobe PSE 15+ and after saving your images, bring them into another image editor like the ones mentioned below and resave the image
  - Just use another image editor other than Adobe. Resizing/rescaling the image using GIMP 2, MS Paint

[Bill]

In Linux the convert magick command in ImageMagick can be used to make a new file that has the JIFI resolution settings. If ImageMagick is installed, open a terminal and run the convert magick command without any options:

Code: Select all

magick input.jpg output.jpg

The input.jpg file is the file that has only EXIF resolution settings. The output.jpg file should also have the JFIF resolution settings.

Edit: changed "convert" to "magick". The magick command should be used instead of convert in the current version of ImageMagick. This change was presumably made because there is already a convert command in Windows.

In addition, there is a "mogrify" command that can be used to add the JFIF settings to the existing file by overwriting the file instead of making a new file. In Linux run the command with no options:

Code: Select all

mogrify input.jpg