Description: I am trying to open a multipage tiff file with Libreoffice (with the intent to export it to PDF), but the error message "Image Filter not found" is popping up. The tiff file seems to be okay as I can open it with other image tools. Steps to Reproduce: 1. open multipage tiff file Actual Results: modal dialog shows "Image Filter not found" and the application gives up. Expected Results: TIFF file content is presented in LibreOffice. Reproducible: Always User Profile Reset: No Additional Info: I tried this on windows and on a Debian headless installation.
Created attachment 193646 [details] Multipage tiff sample file Attached multipage tiff file opens without error with: Version: 24.2.2.2 (X86_64) / LibreOffice Community Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: default; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
On pc Debian x86-64 with master sources updated today or with LO Debian testing package 24.2.0.3, I don't reproduce this. Draw opens with 10 slides containing 1 image each.
I am unable to reproduce this behavior in Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded or Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a2265e8faa099d9652efd12392c2877c2df1d1eb CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Kai, please share a sample TIFF that exhibits the issue, if you can.
Using ImageMagick, I can insert a 201.3 mb image created with: convert -size 5792x5793 xc:pink pink.tif But it fails with a 201.4 mb image created with: convert -size 5793x5793 xc:pink pink.tif So it looks like there's a number of pixels over which the filter fails. No issue if image is e.g. a PNG of the same size. Issue is not related to the size of the file, see bug 160635 in which it fails for a 109 mb picture. Funnily enough, if it fails to insert it into a Calc document, you end up with a Push Button Form Control labelled with the path to the image, and in Writer, with the section dialog. Reproduced in recent own build: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6f4adc1274cfac30b9097411bb193bd4386969f0 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded As well as LO 7.5.9, but not in 7.4.0.3. Bibisected with linux-64-7.5 to first bad build [1ae6bd31aa05c337c00ab8c83f7fdf35ed0c6fe4] which is a5d5c29769d3c744d8a89052842f73dabd71f445, a cherrypick of: commit b05fb34d48da717447b9b86db9546df72b25e988 author Caolán McNamara Sat Apr 01 22:04:32 2023 +0100 committer Caolán McNamara Sun Apr 02 17:44:42 2023 +0200 use the same max size that libtiff defaults to for its own utilities Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149922 Indeed, the patch defines: nMaxPixelsAllowed = (256 * 1024 * 1024) / 4 ... which is later divided by 2, so a max of 33,554,432 pixels, which matches the 5793x5793 import failing. So that was by design, but I guess we could fail more gracefully. What do you think, Caolán?
*** Bug 161299 has been marked as a duplicate of this bug. ***
(In reply to Stéphane Guillou (stragu) from comment #5) ... > > Indeed, the patch defines: > > nMaxPixelsAllowed = (256 * 1024 * 1024) / 4 > > ... which is later divided by 2, so a max of 33,554,432 pixels, which > matches the 5793x5793 import failing. > > So that was by design, but I guess we could fail more gracefully. What do > you think, Caolán? This limit has been lessened from previous release... Version: 7.3.1.3 Build ID: 30(Build:3) CPU threads: 4; OS: Linux 5.17; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Request that the previous upper limit be maintained so that existing previously valid .odp files remain valid.
well, we can try it again and see if anything arises. https://gerrit.libreoffice.org/c/core/+/168747
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d28a000130e5739af90e771d46faa630823add29 Resolves: tdf#160635 allow larger tiff images It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
done in trunk, backport to 24.8 and 24.2 in gerrit.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/f282dbd88aecf38bb817ba51ea8bbdaedfd7d8be Resolves: tdf#160635 allow larger tiff images It will be available in 24.8.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/302dde87c1ccf1163131ed2794f54add290757d3 Resolves: tdf#160635 allow larger tiff images It will be available in 24.2.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 161609 has been marked as a duplicate of this bug. ***