[AI] Fix raw denoise output corrupted DNG / process crash on some libtiff builds#20898
Conversation
|
@andriiryzhkov unfortunately this didn't fix the issue, this is the current output: As I mentioned I am running libtiff-4 in version 4.5.1, which one are you using on your machine? |
|
Do you have the same error on nightly build? |
|
With todays current master
|
|
Please try it on the nightly build AppImage. |
Sorry, not possible, have FUSE and AppImages banned from my System because of very negative experiences. Only using deb packages or self build software, no snap, no flatpak, no AppImage. |
Fixes two symptoms reported in #20854 (comment):
Entry 0x828d not found)ThrowLoggedExceptionassertion in ImageMagick) on some images, in both CPU and MIGraphX modesBoth trace to libtiff CFA / DNG extension tag info handling on the SubIFD in the canonical Adobe layout (IFD0 = JPEG preview, SubIFD0 = raw payload) introduced in #20854.
Fixes
1. Re-initialize SubIFD tag info. After
TIFFWriteDirectory(IFD0), some libtiff packagings drop the registered field info for CFA / DNG extension tags. The nextTIFFSetField(TIFFTAG_CFAREPEATPATTERNDIM, ...)then silently fails - producing a DNG without the CFA pattern that rawspeed can't decode. One-line fix: callTIFFCreateDirectory(tif)between IFD0 commit and SubIFD population. Applied in bothdt_imageio_dng_write_cfa_bayeranddt_imageio_dng_write_linear. No-op on libtiff builds that already retained the tag info.2. Install our own libtiff error/warning handlers. When the unknown-tag error fires on systems where ImageMagick has installed itself as the global libtiff error handler, ImageMagick's
TIFFReadErrorscallsThrowLoggedException(NULL, ...)and aborts. Same pattern asimageio_tiff.calready uses: handlers log to stderr and never abort, overriding whatever else is in the process.