Bug 138981 - The JPG property lost on copy/paste from clipboard (not-libreOffice internal clipboard) causing image being pasted as "unknown format" resulting in JPG to PNG conversion on save
Summary: The JPG property lost on copy/paste from clipboard (not-libreOffice internal ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.7.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: perf
Depends on:
Blocks: Image-DPI
  Show dependency treegraph
 
Reported: 2020-12-16 20:08 UTC by Telesto
Modified: 2024-02-07 08:51 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (8.83 MB, image/jpeg)
2020-12-16 20:09 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-12-16 20:08:54 UTC
Description:
Slow save because paste clipboard image gets converted to PNG

Steps to Reproduce:
1. open the attached image in a browser
2. Copy it
3. Paste in writer
4. Save the document

Actual Results:
Temporally hang

Expected Results:
I assume jpg format info being included in the clipboard, so don't get the conversion. Else speed up of PNG conversion.. which reported already


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.2.0.0.alpha0+ (x64)
Build ID: 15e4427e8fb56a143caa28b8a3120f3761fc77a5
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 1 Telesto 2020-12-16 20:09:18 UTC
Created attachment 168236 [details]
Example file
Comment 2 Telesto 2020-12-16 20:13:25 UTC
Also in 4.4.7.2 and 4.3.0.3

4.2 refused to paste
Comment 3 Telesto 2020-12-16 20:15:19 UTC
Ok, issue with pasting from webbrowser.. paste does work with IrfanView.. also in
LibreOffice 3.5.7.2 
Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
Comment 4 Telesto 2020-12-29 10:32:50 UTC
@Tomaz,
Probably unrelated to you currently refactoring.. but you're nearby based on the commits in gerrit.. so might relevant one way or another.. feel free to un-cc again if out of scope/irrelevant/uninteresting etc
Comment 5 Xisco Faulí 2021-02-15 17:55:56 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2021-08-16 03:50:08 UTC Comment hidden (obsolete)
Comment 7 QA Administrators 2021-09-16 03:28:10 UTC Comment hidden (obsolete)
Comment 8 Telesto 2021-09-16 08:16:13 UTC
Still present
Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: d5e55d204b71710eb5eb5d2c683dd6698626df3c
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

There is another report about this. I have seen it recently. The issue that the source format isn't detected. It's marked as "unknown". Which triggers - as fallback - conversion at save..
Comment 9 QA Administrators 2021-09-17 03:53:51 UTC Comment hidden (obsolete)
Comment 10 Telesto 2022-01-03 12:31:23 UTC Comment hidden (obsolete)
Comment 11 Telesto 2022-01-03 12:36:12 UTC Comment hidden (obsolete)
Comment 12 QA Administrators 2024-02-05 03:12:09 UTC Comment hidden (obsolete)
Comment 13 Mike Kaganski 2024-02-07 06:01:05 UTC
(In reply to Telesto from comment #10)
> *** Bug 146530 has been marked as a duplicate of this bug. ***

(In reply to Telesto from comment #11)
> *** Bug 144070 has been marked as a duplicate of this bug. ***

Please  don't add duplicates that aren't duplicates.

This specific bug 138981 is about the *hypothetical* possibility to "detect" the original file format from the data put to clipboard on a specific OS (Windows) by an *unspecified* browser, when you copy an *unspecified* image using *unspecified* method (do you right-click the image and use an item like "copy the image to clipboard"? select the web page content starting before the image, ending after, and Ctrl+C?). This *might* be possible to improve, by analyzing HTML format that the browser puts into the clipboard; possibly browser-specific and/or OS-specific. E.g., opening https://i.imgur.com/BCftIFD.jpeg in Chrome, right-clicking it in the browser, and copying, gives these formats in my Win11's clipboard: PNG; CF_DIB5; CF_BITMAP; CF_DIB; and HTML Format, the latter only containing a fragment with the image URL. Only the latter allows to discover the source of the file, and thus, to keep the original bytes.

Bug 146530 is about the content of the clipboard after closing LibreOffice itself. This is a different thing; there is no "HTML source" of the image in the clipboard; and here, the clipboard does not contain JPEG at all - just because Windows clipboard has no pre-defined standard format for JPEG images. There could be a workaround. It could be completely different on other OSes (but that would depend on the raster format preferrence; I can imagine that PNGs would always be preferred over lossy formats, when there's no way to discover what was the original format; so that would also need to provide some custom clipboard format, unusable by anything except LibreOffice, just in anticipation of users who close the program, then open it again ... even if this is implemented, it's completely different).

And finally, Bug 144070 is absolutely unrelated to clipboard. It is just about some internal problem, related to a specific JPEG file in the document. E.g., if you try with a document created for bug 146530, and save it as DOCX, the resulting file will still contain a JPEG, so this is something specific.

Marking all these as duplicates effectively made them hidden, and prevents people from working on these.