Changes between Initial Version and Version 1 of Ticket #18204, comment 5
- Timestamp:
- 07/04/2023 03:22:50 AM (21 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TabularUnified Ticket #18204, comment 5
initial v1 1 For processing raw photos (e.g. in identify or display) it seemed that of all the recent format examples I accumulated in the past 10+ years when looking at possible camera purchases, a few (leica rwl files) do not have a delegate, the remaining files (canon cr2, fuji raf, leica dng, nikon nef and nrw, olympus orf, panasonic rw2, pentax pef, sony arw) ALL need ufraw-batch as a delegate. This SHOULD be a runtime delegate, I'm currently on an older system where IM used to work for at least some of these, but now it seems to be using ufraw-batch to convert the images to 16-bit png, but then tries to open a non-existent /tmp 'ppm' image (a valid format for ufraw).1 **Edit**: Remove *most* of what I originally wrote, it appears I must have configured using --with-raw=no while trying to understand what libraw did, and also it seems both 7.1.1-11 and 7.1.1-12 will (in a default build with libraw_r available and not specifying anything) use that as the delegate library - it will be linked from 7.1.1/modules-Q16HDRI/coders/dng.so to the multithread libraw_r.so.NN. 2 2 3 On the one image where I've tried this after reinstating ufraw-batch it *did* create a valid png image with the same basename. I'm 99% certain I could open my own rw2 and orf images with 7.1.1-11, so I now think 7.1.1-12 seems to be buggy (not the first time!).3 In the absence of libraw_r being linked from that solib, but with (old) ufraw (which no-longer compiles following the latest exiv changes), ufraw-batch in both 7.1.1-11 and 7.1.1-12 seems to have broken since ImageMagick asks for a 16-bit png but then tries to open a ppm of the same temporary name (although the png actually exists). 4 4 5 There is a further problem with that, ufraw-batch is from the old ufraw fork on github, that has not been updated in years. I reinstated a git version at some time in the past, but that has broken with exiv2-0.28 and I am unable to fix it. There are patches for the nufraw fork to allow that to build (many of the same errors from exiv2, but ufraw hasd at least one other). On my new system I've tried symlinking ufraw-batch to nufraw-batch, but I do not yet know if that will work, and I need to get a properly working build (maybe 7.1.1-11) on the old system where I have a ufraw-batch **before** booting the new system to test it.5 Since libraw_r can do the job, no point in mentioning ufraw any more, nor in providing a hint about nufraw. 6 6 7 I'm also unsure what libraw provides here (looks at configure, swears loud and long). 8 It looks as if **--with-libraw=yes needs to be specified** to use it : /usr/lib/ImageMagick-7.1.1/modules-Q16HDRI/coders/dng.so will then link to the multithread libraw_r.so.NN. 9 10 That works in 7.1.12 on my old system with 7.1.1-12 rebuilt and ufraw-batch unavailable: 11 All my example raw files **except leica rwl** now work with ImageMagick. If I ever need to use those I can do what I do when adjusting my own images: 'nufraw --out-type=png --out-depth=16 --clip=film filename.typ'. LibRaw is a **delegate library**, preferred to delegate programs so I'm now tending towards dropping the ufraw dependency because KibRaw is preferred, can handle most files, and original ufraw is now broken by exiv2. 12 13 If anyone else needs nufraw, see Arch (they call it gimp-nufraw) for patches. I don't use cfitsio nor lensfun - tried lensfun using the Arch instructions 4½ years ago, nufraw crashed and there was no option to compile nufraw without lensfun whilst lensfun was present. 14 15 Will boot the new system to measure this, somewhen. 7 For the leica rwl examples I had, renaming them to either raw or rw2 (synonyms in ImageMagick's coders/dng.h) allows them to be processed by ImageMagick.
