If an image made with a camera which does not exist in the lensfun database is loaded and the camera is set to the closest match (e.g. image taken with Olympus E-M1 MarkII, camera set in ufraw to "Olympus, E-M1) ufraw writes the CameraModel to the .ufraw file: <CameraModel>Olympus, E-M1</CameraModel> in the <LensFun> section. Ufraw will correctly load from this ufraw file. However, when it loads, no potential lens information is present in the dropdown. If one then manually resets the camera model to the same model shown, the potential lens info is shown. If a new ufraw file is now written, it will contain the lens information but no camera information. Attempting to load this file will cause ufraw to crash. Adding any camera information manually to the .ufraw file will also cause ufraw to crash, whether the camera is in the database or not, apparently because the camera does not match the one given in the loaded image.
Can you provide a sample picture with no personal datas (a picture of a tree will be perfectly fine) I can use to test ?
http://www.dreamchaser.org/garya/misc/Bug_226544.orf The following change to graphics/lensfun/mil-olympus.xml does not fix the problem, but makes it go away for this particular camera if that's a help: *** mil-olympus.xml_org Sun Nov 15 10:07:26 2015 --- mil-olympus.xml Mon Mar 12 08:29:34 2018 *************** *** 121,126 **** --- 121,134 ---- </camera> <camera> + <maker>OLYMPUS CORPORATION</maker> + <maker lang="en">Olympus</maker> + <model>E-M1MarkII</model> + <mount>Micro 4/3 System</mount> + <cropfactor>2.0</cropfactor> + </camera> + + <camera> <maker>Olympus Imaging Corp.</maker> <maker lang="en">Olympus</maker> <model>E-M5</model>
ufraw will probably not crash with the supplied .orf if you are using a current development version of lensfun -- according the the big history, the e-m1markii was added to the db about the middle of last year. It will crash with the current production version which is in the ports tree.
Hi, Thanks for the feedback. I completely agree with the suggestion you made in the ports ML, and we should try the https://github.com/sergiomb2/ufraw.git version since its more updated and it supports your camera (AFAIK). Since you are trying to move ufraw to github, I will give more time to complete this task and come back with a nice, working patch :) By the way, if you have any issue doing this task, or need a revies, feel free to ask, I'll be happy to help you. All the best, - rodrigo
Hi, In the meantime I got a build for ufraw from github repo, please try it and give me a feedback : https://people.freebsd.org/~rodrigo/ufraw-0.22_4.txz I did tests with the picture you provide ant it looks promising.
(In reply to Rodrigo Osorio from comment #5) Tried out your build, but it still fails. (The github development version of ufraw does not solve the problem.) It may be the sequence of operations is unclear. Here's what I did to reproduce it: 1. Check /usr/local/share/lensfun/version_1/mil-olympus.xml to be sure it does not have an entry for E-M1MarkII: $ grep -i markii mil-olympus.* mil-olympus.xml: <model>E-M5MarkII</model> it should not have this: mil-olympus.xml_fixed: <model>E-M1MarkII</model> 2. cd to the directory with the image 3. ufraw image.orf 4. Go to lens correction tab and set camera model to "E-M1" 5. Set lens to "Olympus, Olympus M.Zuiko Digital ED 12-40mm f/2.8 Pro" 6. Click "Save" 7. Notice the saved .ufraw file has the camera model under <CameraModel> 8. ufraw image.ufraw => core I have a devel port more or less ready to go (without any fixes), but am waiting for info from the original developer (udifuchs@gmail.com) or his follow-on to see what the current status is in terms of development, and to get permission to push fixes. I haven't heard from either, so I'm unclear how to proceed. I'm not dead certain the github source is now the "official" source, or who is in charge of it.
I'm sorry for that, I just commit the changes to move ufraw from SF to GH, but I can't do more. If the bug remains it should be reported to upstream. In that case is https://github.com/sergiomb2/ufraw. BTW, the github repo is a fork, not handled by the project founders, but that's open source ecosystem, when someone drops it's project, you are free to fork and continue the work.
UFRaw is an unmaintened project, the port was updated to point to a new upstream ( https://github.com/sergiomb2/ufraw), who tries to maintain / fix existing issues. The current bug was reported to the new upstream.