Project

General

Profile

Bug #10739

Image overexposed in dark-/lighttable when compared to exported image

Added by Kristian Niemi over 3 years ago. Updated over 3 years ago.

Status:
Fixed
Priority:
Low
Assignee:
Category:
Darkroom
Start date:
11/24/2015
Due date:
% Done:

100%

Affected Version:
git development version
System:
all
bitness:
64-bit
hardware architecture:
amd64/x86

Description

Sometimes, the exposure shown in darktable is very different (like +2EV) from what is actually exported.

Device Name: "Onboard IGD" 
Model: "Intel Haswell Integrated Graphics Controller"
Vendor: pci 0x8086 "Intel Corporation"
Device: pci 0x0412 "Haswell Integrated Graphics Controller"
SubVendor: pci 0x1043 "ASUSTeK Computer Inc."
SubDevice: pci 0x8534
Revision: 0x06
Driver: "i915"

[ 3.062] (II) LoadModule: "intel"
[ 3.062] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so
[ 3.066] (II) Module intel: vendor="X.Org Foundation"
[ 3.066] compiled for 1.17.4, module version = 2.99.917
[ 3.066] Module class: X.Org Video Driver
[ 3.066] ABI class: X.Org Video Driver, version 19.0

Attaching an exported jpg, output of "darktable -d all" when exporting, an xmp, and a screenshot from darktable. Note how both image in darktable and thumb are quite overexposed but the jpg looks OK. Can't attach NEF due to size restrictions. It is available here: https://www.dropbox.com/sh/orxut7ikzm5h43i/AACzC31puMzhqdbs_i2-qVGma?dl=0

darktable__debug--151124_2000 - output of 'darktable -d all' (339 KB) Kristian Niemi, 11/24/2015 09:34 PM

screenshot.png - screenshot of overexposed dark-/lighttable (1.08 MB) Kristian Niemi, 11/24/2015 09:35 PM

151030_151316_Manuskript.NEF.xmp (6.37 KB) Kristian Niemi, 11/24/2015 09:35 PM

151030_151316_Manuskript_01.jpg (8.02 MB) Kristian Niemi, 11/24/2015 09:35 PM

Associated revisions

Revision c375f990
Added by Roman Lebedev over 3 years ago

Exposure iop: deflicker: adapt to non 14-bit input data. Fixes #10739.
Breaks history stacks.

This removes "histogram of" selection, only histogram of source raw
buffer makes sense.

Also, hardens checks for when deflicker can be used - only if original
input buffer is uint16_t.

Yes, this breaks history stacks.
But deflicker (still) hasn't been officially released
exactly for this reason, so... :(

History

#1 Updated by Roman Lebedev over 3 years ago

  • System changed from other GNU/Linux to all
  • % Done changed from 0 to 10
  • Assignee set to Roman Lebedev
  • Status changed from New to Confirmed

#2 Updated by Roman Lebedev over 3 years ago

  • % Done changed from 10 to 100
  • Status changed from Confirmed to Fixed

Also available in: Atom PDF