Project

General

Profile

Bug #9562

Missing “color matrix” input color profiles (Fuji X100)

Added by Ben Beasley almost 7 years ago. Updated over 6 years ago.

Status:
Fixed
Priority:
Medium
Assignee:
-
Category:
-
Target version:
-
Start date:
08/21/2013
Due date:
% Done:

100%

Estimated time:
Affected Version:
git development version
System:
Fedora/RHEL
bitness:
64-bit
hardware architecture:
amd64/x86

Description

I was successfully using darktable to process raw files from my Fuji X100 until Fedora 18 pushed an update from 1.0.5-3 to 1.2.2-1. Now I no longer have input color profile options for “standard color matrix” or “enhanced color matrix” (see attached screenshot). The behavior is the same in git master 2b5ab63d521f733f6de3b022a3748bb8458dc04f.

I’ve noticed that darktable now reports “[rawspeed] No decoder found. Sorry.” for all images, raw or jpeg. I wonder if this is related.

Downgrading to 1.0.5-3 and blowing away my ~/.config/darktable/ seems to fix the problem.

I’d be happy to do any tests necessary to help figure out how to resolve this and make current darktable versions usable to me again.

darktable_profile_problem.png (762 KB) darktable_profile_problem.png Screenshot showing deficient input profile list. Ben Beasley, 08/21/2013 05:05 AM
DSCF0602.RAF (19 MB) DSCF0602.RAF Raw file shown in screenshot. Ben Beasley, 08/21/2013 05:05 AM

History

#1 Updated by Ben Beasley almost 7 years ago

1.1.4 from git works fine. I suppose I should continue building and testing until I figure out exactly when the change occurred. I'm seeing the [rawspeed] error on 1.1.4 as well, so that must be unrelated to this.

#2 Updated by Pascal de Bruijn almost 7 years ago

Try the darktable-1.1.x branch, it's still the 1.1 series but with lots of new stuff from 1.2 and master backported, that'll probably give you a nicer solution for the mean time.

With regard to 1.2.x or master, I think this is an EXIF handling regression, so your camera make isn't being matched to find the matrices.

#4 Updated by Ben Beasley over 6 years ago

You’re definitely right about the cause.

I decided to start with git master and try restoring the following four lines

  g_strlcpy(img->exif_maker, raw->idata.make, sizeof(img->exif_maker));
  img->exif_maker[sizeof(img->exif_maker) - 1] = 0x0;
  g_strlcpy(img->exif_model, raw->idata.model, sizeof(img->exif_model));
  img->exif_model[sizeof(img->exif_model) - 1] = 0x0;

of those that were #define'd out in the commit you linked to. This gives me back the “color matrix” options. (Of course, it might re-introduce other problems I’m not aware of.)

#5 Updated by Johannes Hanika over 6 years ago

Pascal de Bruijn wrote:

I'm guessing this might be the culprit:

https://github.com/darktable-org/darktable/commit/5668c8d14362d375a92d2b2290f0dd3a06058caf

we need that commit to make the same scenario work for pentax cameras for example. also lensfun uses the exiv2 naming scheme, and the libraw exif override will only take place when loading the raw, not when importing the image (thus changing weirdly at some point in time in the background). the only good solution i see is to always use the exiv2 model/maker strings everywhere in the code.

#7 Updated by Ben Beasley over 6 years ago

  • % Done changed from 0 to 100
  • Status changed from New to Fixed

Confirmed, Johannes fixed it. Thanks!

Also available in: Atom PDF

Go to top