Description: When inserting a JPEG file tagged as rotated, Writer first loads the image and then rotates the image, tanking several seconds on the process. Steps to Reproduce: 1. Insert image Actual Results: The image is inserted after waiting up to 15 seconds. Expected Results: Image inserted instantly. Reproducible: Always User Profile Reset: No Additional Info: It takes more time when images have bigger resolution and wheen the file has already more than a 100 images inserted. If the image file is not tagged as rotated, the insertion takes no time at all.
Thank you for reporting the bug. As Mike Kaganski wrote in Lo Ask "If you can, please file a bug with a sample images attached, which are rotated and non-rotated, and which show the described problem. Thanks." So please attach some images. Thank you => NEEDINFO
Created attachment 179688 [details] ODT and JPEG files I attached three files: Two JPEG files, one that is rotated and the other files that is not rotated. One ODT file, with the two images inserted inside table cells. The issue can be repeated inserting the images in any ODT file. I think this issue can be solved if there is a JPEG library that can load the image rotated instead of rotating the image after beeing loaded.
[Automated Action] NeedInfo-To-Unconfirmed
I confirm it with Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: d34d1db55978bdcff082af1e0f75b18fa6fc94f4 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL Actual result: Inserting image took around 22 seconds Expected result: < 3 seconds
Dear Claudio Bogado, 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
It still takes 15 seconds to insert rotated image with Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0480e84e4c0b43d3829d83746636ad7a7037e76e CPU threads: 12; OS: Windows 11 X86_64 (build 22631); UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded
Likely fixed in the Master build of tomorrow. See bug 137848
I believe I ran into this bug today using Version: 24.8.4.2 (X86_64) / LibreOffice Community Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002 CPU threads: 72; OS: Linux 4.18; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded * This seems to affect exif-rotated images and is likely a wide-spread issue. Recent Samsung phones(tested on S22 and A52) take portrait photos as landscape and just use EXIF metadata to tell the viewer to rotate the image. * When LibreOffice inserts these images, it takes forever because it is CONVERTING THEM INTO PNG. This blows up the drawing size, turning a 3.5MB image into a 12.6MB drawing. And that was a single image! * You can verify the image has been converted into PNG by right-clicking on the image in Draw/Writer and clicking "Compress...". You'll see its "Type" under "Image Information" is now a PNG image, not JPG. * This affects not only Writer, but Draw, Calc, and any other LO component when using Insert -> Image Note: * It only converts to PNG if I use Image -> Insert. I don't experience this issue if I drag and drop an image from another application (file-manager, image viewer, copy/paste). When I drag/drop from another application it ignores the rotation EXIF metadata and inserts the image un-rotated, but at least keeps it as a JPG. * In the "Compress..." dialog, you can change the image back to JPG compression to reduce file size. * If you run "jhead -autorot" on the images before-hand, you can apply the rotation and avoid LibreOffice converting them into PNG.
I'm unable to reproduce the issue with Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a8ec21adf255b70bb6eeb0a1717190df303d8b26 CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL threaded When using Insert -> Image. So probably fixed in 25.8.0 I do still reproduce the issue when inserting an image with drag & drop
I just tested it in last night's nightly and can still reproduce the problem. I tested in: Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1fc03eaed2899ac041f660f54cb1facb71390ccf CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: x11 Locale: en-US (en_US.utf8); UI: en-US Calc: threaded For giggles, I confirmed this is also reproducible under Windows 24.2.5.2, so it definitely is the same issue that I'm seeing under Linux. If you need help reproducing, make sure you're testing with IMG_20220404_143722388.jpg from the attached example files, since IMG_20220404_143656478.jpg isn't rotated and doesn't experience the issue. * New Drawing * Insert -> Image... * IMG_20220404_143722388.jpg from attached files * Right Click inserted image -> Compress... * Look at "Type" (should be JPEG, not PNG)