Description: When trying to open different tiff formats exported from another program, LO would return and unknown format message. Five of the six formats were open by wordpad and copying the image there did paste into LO. And older tif format is indeed supported by LO, though not one my photo editing program exports to. Tried in Writer and Calc. Not sure of whether earlier versions are affected by this bug. Steps to Reproduce: Either dragging and dropping on Calc or inserting image in Calc and Writer. Actual Results: Unknown format message shown. Calc shows a rectangle with path to image when dropping and nothing if inserting with icon or insert menu. Nothing shown in Writer. Expected Results: Image shown. Reproducible: Always User Profile Reset: No Additional Info: Versión: 6.3.3.2 (x64) Id. de compilación: a64200df03143b798afd1ec74a12ab50359878ed Subprocs. CPU: 8; SO: Windows 10.0; Repres. IU: GL; VCL: win; Configuración regional: es-ES (es_ES); Idioma de IU: es-ES Calc: threaded
Created attachment 158464 [details] Samples of different tiff files There are six samples, each with a different filter applied.
On pc Debian x86-64 with master sources updated today, I could reproduce this. But using "tiffinfo" program showed some pb with all the tiffs, eg: tiffinfo -D clavijo8bit.tiff TIFFReadDirectory: Warning, Unknown field with tag 51168 (0xc7e0) encountered. TIFFFetchNormalTag: Warning, Incompatible type for "RichTIFFIPTC"; tag ignored. TIFF Directory at offset 0x4d3dec (5062124) Image Width: 2601 Image Length: 3503 Resolution: 96, 96 pixels/inch Bits/Sample: 8 Compression Scheme: AdobeDeflate Photometric Interpretation: RGB color Orientation: row 0 top, col 0 lhs Samples/Pixel: 3 Rows/Strip: 1 Planar Configuration: single image plane DateTime: 2020:03:07 10:19:17 XMLPacket (XMP Metadata): ... TIFFReadCustomDirectory: Warning, Wrong data type 3 for "PixelXDimension"; tag ignored. TIFFReadCustomDirectory: Warning, Wrong data type 3 for "PixelYDimension"; tag ignored. ...
Repro also Version: 7.0.0.0.alpha0+ (x64) Build ID: cf96cb11e2a46c452a273ded1c66c556118983cf CPU threads: 4; OS: Windows 10.0 Build 19577; UI render: Skia/Raster; VCL: win; Locale: es-ES (es_ES); UI-Language: en-US Calc: threaded
It happens with Aoo 4.1.7, so inherited. Not all files open with Photos in win10
Dear lbartolome, 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
Still rerpo in Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 3ccc4c123f5e78e0204d11abeab2d1a74278ca3e CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: threaded
If the tiff file is not valid (see https://bugs.documentfoundation.org/show_bug.cgi?id=131199#c2), we can expect LO doesn't recognize properly, can't we?
(In reply to Julien Nabet from comment #7) > If the tiff file is not valid (see > https://bugs.documentfoundation.org/show_bug.cgi?id=131199#c2), we can > expect LO doesn't recognize properly, can't we? I don't know. But image viewer IrfanView opens all 6 of them, so LO should also.
I read more about tiff recently and there are 2 things to consider here: 1) in LO, Adobe deflate (compression = 8) isn't taken into account in tiff import mechanism 2) different photometric interpretation in the 6 files: Photometric Interpretation: min-is-black Photometric Interpretation: CIE L*a*b* Photometric Interpretation: RGB color Photometric Interpretation: min-is-black Photometric Interpretation: RGB color Photometric Interpretation: separated If I just do "git grep -n nPhotometricInterpretation itiff.cxx" (see https://opengrok.libreoffice.org/xref/core/vcl/source/filter/itiff/itiff.cxx?r=891ff133), I got: itiff.cxx:77: sal_uInt32 nPhotometricInterpretation; itiff.cxx:150: , nPhotometricInterpretation(0) itiff.cxx:377: nPhotometricInterpretation = ReadIntData(); itiff.cxx:378: SAL_INFO("filter.tiff","PhotometricInterpretation: " << nPhotometricInterpretation); itiff.cxx:865: nPlanes == 1 && nPhotometricInterpretation == 2 ) itiff.cxx:906: ( nPhotometricInterpretation == 2 && nSamplesPerPixel >= 3 ) || itiff.cxx:907: ( nPhotometricInterpretation == 5 && nSamplesPerPixel == 3 ) itiff.cxx:927: if (nPhotometricInterpretation == 2) itiff.cxx:934: else if( nPhotometricInterpretation == 5 && nSamplesPerPixel == 4 ) itiff.cxx:977: else if ( nSamplesPerPixel == 1 && ( nPhotometricInterpretation <= 1 || nPhotometricInterpretation == 3 ) ) itiff.cxx:1190: if ( nPhotometricInterpretation <= 1 ) itiff.cxx:1206: if ( nPhotometricInterpretation == 1 ) itiff.cxx:1263: nPhotometricInterpretation == 2; itiff.cxx:1396: nPhotometricInterpretation = 0; itiff.cxx:1474: if ( nPhotometricInterpretation == 2 || nPhotometricInterpretation == 5 || nPhotometricInterpretation == 6 ) So "CIE L*a*b*" (which has code 8, see https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pdf), isn't implemented at all. Quoting again Wikipedia: " TIFF is a complex format, defining many tags of which typically only a few are used in each file. This led to implementations supporting very varying subsets of the format, a situation that gave rise to the joke that TIFF stands for Thousands of Incompatible File Formats.[8] This problem was addressed in revision 6.0[7] of the TIFF specification (June 1992) by introducing a distinction between Baseline TIFF (which all implementations were required to support) and TIFF Extensions (which are optional). Additional extensions are defined in two supplements to the specification, published September 1995[9] and March 2002,[citation needed] respectively." I think we should consider this one more than an enhancement and seeing the number of different combinations in tiff. The best thing to do would be to use libtiff lib to delegate the tiff management but Tomaž indicated it required a lot of work. Now about Irfanview, as an image viewer, we can expect it tries to respond about its very core feature.
Caolán: with master sources updated today (11e4235930f05906311f7b70444b0a6487d59a47, tiff: enable webp), I could open 5 on the 6 files. For the 5 OK, I just noticed this log: TIFFReadDirectory: Warning, Unknown field with tag 51168 (0xc7e0) encountered but no big deal I suppose. For the 6th, it's clavijo16bitlab.tiff tiffinfo gives: Image Width: 2601 Image Length: 3503 Resolution: 96, 96 pixels/inch Bits/Sample: 16 Compression Scheme: AdobeDeflate Photometric Interpretation: CIE L*a*b* Orientation: row 0 top, col 0 lhs Samples/Pixel: 3 Rows/Strip: 1 Planar Configuration: single image plane ... so CIE lab.
that 6th one also doesn't open with "eog" for me (well it appears blank), but does seem to work with imagemagicks "display"
I gave a try on gdb, at this line: 204 if (TIFFRGBAImageOK(tif, emsg) && TIFFRGBAImageBegin(&img, tif, 1, emsg)) it doesn't enter the if block.
Searching in libtiff, I see functions like: TIFFCIELabToRGBInit TIFFCIELabToXYZ TIFFXYZToRGB so perhaps there's not much to do since libtiff seems to deal with CIELab
Ok digging a bit more in libtiff/tif_getimage.c TIFFRGBAImageOK method precisely and here's the pb: Thread 1 "soffice.bin" hit Breakpoint 1, TIFFRGBAImageOK (tif=0x943a3d0, emsg=0x7ffdc958f5b0 "") at tif_getimage.c:197 197 if ( td->td_samplesperpixel != 3 || colorchannels != 3 || td->td_bitspersample != 8 ) { (gdb) p td->td_samplesperpixel $1 = 3 (gdb) p colorchannels $2 = 3 (gdb) p td->td_bitspersample $3 = 16 emsg is empty but here's the whole block: 197 if ( td->td_samplesperpixel != 3 || colorchannels != 3 || td->td_bitspersample != 8 ) { 198 sprintf(emsg, 199 "Sorry, can not handle image with %s=%"PRIu16", %s=%d and %s=%"PRIu16, 200 "Samples/pixel", td->td_samplesperpixel, 201 "colorchannels", colorchannels, 202 "Bits/sample", td->td_bitspersample); 203 return 0;
I got something now which seems to basically work for the last case: https://gerrit.libreoffice.org/c/core/+/134734
effort to submit upstream as: https://gitlab.com/libtiff/libtiff/-/merge_requests/336
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5b74eb7d41bbcf2d35154ae8272f0e71be128b60 tdf#131199 add some basic 16bitcielab support It will be available in 7.4.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.
(In reply to Caolán McNamara from comment #16) > effort to submit upstream as: > https://gitlab.com/libtiff/libtiff/-/merge_requests/336 I confirm it works! Hope libtiff team will merge your patch quickly.
Just in case because the notification was in my spam, there's been a feedback here: https://gitlab.com/libtiff/libtiff/-/merge_requests/336#note_956354180