Bug 160635 - open or insert a TIFF image over 33,554,432 pixels fails in various ways ("Image Filter not found" in sd, Section dialog in sw, Push button in sc)
Summary: open or insert a TIFF image over 33,554,432 pixels fails in various ways ("Im...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
7.5.3.2 release
Hardware: All All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:25.2.0
Keywords: bibisected, bisected
: 161299 (view as bug list)
Depends on:
Blocks: Image-Caching Images-TIFF
  Show dependency treegraph
 
Reported: 2024-04-12 04:24 UTC by Kai
Modified: 2024-06-12 19:31 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Multipage tiff sample file (4.20 MB, image/tiff)
2024-04-12 10:57 UTC, m_a_riosv
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kai 2024-04-12 04:24:54 UTC
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.
Comment 1 m_a_riosv 2024-04-12 10:57:04 UTC
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
Comment 2 Julien Nabet 2024-04-12 12:45:43 UTC
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.
Comment 3 Armondo Lopez 2024-04-13 15:01:20 UTC
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
Comment 4 Stéphane Guillou (stragu) 2024-05-16 12:49:02 UTC
Kai, please share a sample TIFF that exhibits the issue, if you can.
Comment 5 Stéphane Guillou (stragu) 2024-06-12 03:17:21 UTC
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?
Comment 6 Stéphane Guillou (stragu) 2024-06-12 03:18:52 UTC
*** Bug 161299 has been marked as a duplicate of this bug. ***
Comment 7 Fred 2024-06-12 03:59:56 UTC
(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.
Comment 8 Caolán McNamara 2024-06-12 15:04:47 UTC
well, we can try it again and see if anything arises.
https://gerrit.libreoffice.org/c/core/+/168747
Comment 9 Commit Notification 2024-06-12 19:14:27 UTC
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.
Comment 10 Caolán McNamara 2024-06-12 19:31:36 UTC
done in trunk, backport to 24.8 and 24.2 in gerrit.