Fix libtiff 4.7 compat #4319
Fix libtiff 4.7 compat #4319
Conversation
Don't bail out if TIFFReadScanline() and TIFFReadEncodedStrip() return -1. libtiff 4.7.0 and maybe earlier have started returning error values for truncated strips. Maybe other API points now return error codes for warnings too? see #4317
ed5f6c4 to
140d14f
Compare
|
I think https://gitlab.com/libtiff/libtiff/-/merge_requests/628 might be the upstream change, which appears to zero out any scan lines that cannot be decoded due to the warning. Is it safe to ignore the return code with older versions of libtiff? |
|
Ah it's all unclear. Thinking about this again, I think (I think!) libtiff policy is to only return error codes for unrecoverable errors and not for warnings, so this change is probably a libtiff bug. I suppose in that case you're right and we should just |
|
Test file from linked issue for reference: https://github.com/user-attachments/files/18116811/error_tiff.zip With libtiff 4.7.0, TIFFReadScanline() returns -1 for scanline 7212, while earlier libtiffs keep on trucking and just issue warnings. |
|
I made an issue on libtiff, let's see what they say. |
|
The result of the libtiff discussion is that we need to revise our error handling in tiff2vips. Read functions like |
|
It sounds like this could build quite nicely on top of #4313, so perhaps we should target this fix at 8.17/master? |
|
I agree, let's junk this and try again on master with a more serious reworking of libtiff error handling. I'll make an issue so this isn't forgotten. |
libtiff 4.7 now returns -1 for some warnings
Don't bail out if TIFFReadScanline() and TIFFReadEncodedStrip() return -1.
libtiff 4.7.0 and maybe earlier have started returning error values for
truncated strips.
Maybe other API points now return error codes for warnings too?
see #4317