Beep6581 / RawTherapee

A powerful cross-platform raw photo processing program
https://rawtherapee.com
GNU General Public License v3.0
2.88k stars 323 forks source link

Preview does not match output - exposure and contrast. #1118

Closed Beep6581 closed 9 years ago

Beep6581 commented 9 years ago

Originally reported on Google Code with ID 1133

What is the problem?
Output does not match preview - output significantly lighter/less contrasty than preview.

See:
http://www.capture-the-moment.co.uk/tp/tfu29/upload/RT/RT_preview_crop.jpg - preview;

http://www.capture-the-moment.co.uk/tp/tfu29/upload/RT/fallow_deer_RT.jpg - output.

What steps will reproduce the problem?
Anything: problem appears to be profile/setting/processing independent. No Auto settings
applied, no RAW-tab adjustments - it's simply a mismatch between preview and output.
Not happening with RT 4.0.4/4.0.5, (from RT 4.0.4: http://www.capture-the-moment.co.uk/tp/tfu29/upload/RT/RT_404.jpg)
so not a "local" problem.

The PP3 files from the 4.0.4 and 4.0.6 conversions are identical except for the EPD
section, which is not enabled.

Branch: default
Version: 4.0.6.3
Changeset: 286a06753099
Compiler: GCC 4.6.1
Processor: generic x86
System: Windows
Bit depth: 64 bits
Gtkmm: V2.22.0
Build type: RELEASE
Build flags:  -mtune=generic -O2 -DNDEBUG
Link flags:  -mtune=generic -mwindows -s
OpenMP support: ON
MMAP support: ON

Operating system and architecture (e.g. winXP-32, ubuntu-10.10-64):
Win 7 Premium/64 bit 8gb RAM.

Reported by keith.reeder on 2011-11-30 08:46:28

Beep6581 commented 9 years ago
I'm on a phone so I can't analize your images at the moment. Is your output profile
"No ICM" by any chance? If so, set it to RT_sRGB and retry.

Reported by entertheyoni on 2011-11-30 09:25:57

Beep6581 commented 9 years ago
It's better, but still lighter than the preview or the output from earlier versions
(which are also set to "No ICM" - but because it's actually "No ICM: sRGB Output",
shouldn't it default to sRGB anyway?)

Other alternative output profiles are like RT_sRGB: closer, but not identical to the
preview.

Reported by keith.reeder on 2011-11-30 10:42:41

Beep6581 commented 9 years ago
RT_sRGB is the new default as of revision 5fc887f050d5 14 hours ago.

Can you post an image showing the disparity between your preview and RT_sRGB?

Reported by entertheyoni on 2011-11-30 10:54:52

Beep6581 commented 9 years ago
Yep, some examples here:
http://rawtherapee.com/forum/viewtopic.php?f=3&p=25881#p25881 (first and fourth images).

Reported by keith.reeder on 2011-11-30 11:58:45

Beep6581 commented 9 years ago
Can I suggest that this is NOT a "low priority" defect? An inaccurate preview is about
the the most serious usability issue I can think of.

Reported by keith.reeder on 2011-11-30 18:10:30

Beep6581 commented 9 years ago
If output profile is set to a standard (not RT's own) sRGB or AdobeRGB1998 or ProPhoto
- do you have the issue?

Reported by michaelezra000 on 2011-11-30 18:56:03

Beep6581 commented 9 years ago
I have the same issue:

- wrong preview when image is saved "No ICM: sRGB Output"--> in the processed image
the following profile is embedded "RTsRGB gamma sRGB(ICE 61966 equivalent)
- very very close to RT´s preview when image saved "RT_sRGB"--> in the processed image
the following profile is embedded "RTsRGB gamma BT709(IEC 61966 equivalent)
- no furher output profiles tested so far

Reported by macti@gmx.de on 2011-11-30 20:14:33

Beep6581 commented 9 years ago
What's your working profile?

Reported by entertheyoni on 2011-11-30 20:47:26

Beep6581 commented 9 years ago
I'm away from my machine right now Michael, so I'll test when I get home: but I tried
most of the profiles last night and none of the ones I tried were right - I *think*
I tried the standard sRGB too...

Reported by keith.reeder on 2011-12-01 13:40:45

Beep6581 commented 9 years ago
Yep, happens with every output profile.

Reported by keith.reeder on 2011-12-01 18:12:10

Beep6581 commented 9 years ago
Keith can you retry this using the neutral profile? If that's too dark, then hit Auto
Levels, but nothing apart for that. Just to eliminate everything else. I'm testing
this right now too.

Reported by entertheyoni on 2011-12-01 22:18:32

Beep6581 commented 9 years ago
I notice a slight difference too.
http://min.us/mbiGQQFEN7

Latest RT.

Reported by entertheyoni on 2011-12-01 23:03:09

Beep6581 commented 9 years ago
Can repro, too. Output is lighter than preview. Bad bug :-(

Reported by oduis@hotmail.com on 2011-12-02 07:13:54

Beep6581 commented 9 years ago
It happens with Neutral/Auto Levels/RT_sRGB too, Yoni.

Reported by keith.reeder on 2011-12-02 19:30:57

Beep6581 commented 9 years ago
Sorry I'm late on this, I don't have the problem with 4.0.6.4 Win 7 64

Calibrated monitor, ProPhoto working space, "sRGB color space profile" for output.

No difference in brightness or colors between editor preview and output either on screen
or print (calibrated that too). Editor preview is less sharp (but I expected this from
the fast demosaicing). 

The same changing the working space in sRGB.

I have in "preferences", uder "color management" relative colorimetric, the path for
the ICC directory and the choice of the monitor profile, uncheked the "auto use of
op. sys etc"

Reported by RitaLaCorte on 2011-12-14 12:25:03

Beep6581 commented 9 years ago
How can you possibly compare such subtle differences between screen and print?
Editor preview is not less sharp - sharpening only works at >=100% 

Reported by entertheyoni on 2011-12-14 15:36:54

Beep6581 commented 9 years ago
Still happening in 4.0.6.4 for me.

Reported by keith.reeder on 2011-12-15 19:27:58

Beep6581 commented 9 years ago
Update - this seems to be fixed in the latest "official" release.

Reported by keith.reeder on 2011-12-17 10:12:06

Beep6581 commented 9 years ago
If you tried it initially with the VisualBakery.com version, there is no difference
between that package and the one on the homepage.

Reported by oduis@hotmail.com on 2011-12-17 10:51:01

Beep6581 commented 9 years ago
Yep, I was wrong - it's still happening.

Reported by keith.reeder on 2011-12-17 13:51:52

Beep6581 commented 9 years ago
Same here. Thought it was ignoring the default contrast setting of 20 seems to be ignored
and the value is actually 0 when processing to output. setting it to 40 gives the same
output for me as 20 does on the input. Changing to RT_sRGB does seem to fix it so it
was a ICC issue. Surely you should change the default profile to use RT_sRGB?

Reported by TKshadman on 2012-01-05 14:59:33

Beep6581 commented 9 years ago
Please show screenshots of the preview and output as viewed in RT and some other viewer.
www.imgur.com

Reported by entertheyoni on 2012-01-05 21:25:16

Beep6581 commented 9 years ago
I made a test by using working profile = ProPhoto, and output gamma Low_g2.6_s6.9. The
result was "flat" (low contrast and desturated colors) when rendered in IrfanView,
until i switched on the color handling option (plugin), and then it rendered the same
as in the preview. Window's default viewer and Firefox shown them correctly (same as
in the preview), but of course, my image had metadatas and an ICC/gamma profile included...

About comment 13:

Between which files can we see a difference?

Reported by natureh.510 on 2012-01-06 10:11:45

Beep6581 commented 9 years ago
scrot_* are screenshots of the preview, the others are the processed files resized in
RT to match the preview size. The difference is not great.

In the "a" set, the preview has an ugly red saturated tint to it, the processed files
are nicer, brown not red.

In set "b", you can easily see how the shadows are lighter in the preview.

Reported by entertheyoni on 2012-01-08 05:04:49

Beep6581 commented 9 years ago

Reported by natureh.510 on 2012-01-11 09:51:49

Beep6581 commented 9 years ago

Reported by natureh.510 on 2012-11-14 00:24:53

Beep6581 commented 9 years ago
Can you still reproduce that bug with the latest version? I guess that it has been solved
by the NoICM bugfix from Oduis?

I've made this issue block issue 1403 because i've just experienced a strong difference
between preview and output, but in my case, it's the preview that was lighter, and
with a pink color cast instead of strong reds (which remind me of a forum's topic that
i can't get my hand on anymore). The output settings was NoICM, and same behavior with
output set to RT_sRGB.

I've then checked my color management preference, realized that i was using the wrong
system-wide color profile, so i've chosed the correct one thanks to ProfileChoser (an
ICC profile selector that was bundled with the Spider2Pro), restarted RT and everything
was correct again. I've tried to reproduce the bug but i didn't managed!

The system-wide ICC profiles are LUT based, directly loaded in the Gfx card (as it
should be nowadays?). Why do we bother selecting that very same ICC profile in RT's
preference if the system is corrected by the OS on a per display basis? I've selected
sRGB as monitor profile in RT's preference, which seemed logical to me, and then the
preview was matching the output!

I don't understand what happened, but it might be related to the fact that:
- i'm puting my laptop in "permanent sleep" (i don't know how it's named in english)
- my laptop is connected to an external monitor with the laptop's monitor closed. When
waking up, maybe the system (Win7) doesn't use the correct ICC profile (the laptop's
and external display have their own ICC profile), leading to a wrong behavior.

Reported by natureh.510 on 2012-11-14 02:16:57

Beep6581 commented 9 years ago
I tested all working color profile settings, and then all output color profile settings
using sRGB as working profile, and observed no difference at all between preview and
output, except for some posterization when *g10 profiles were used, but I guess this
difference is because of jpeg being 8-bit (most visible on the green leaf).

I viewed the images in my color-managed Geeqie image browser. I downscaled RT's output
to exactly match the preview size, then aligned the image viewer window precisely over
RT's preview so I could Alt+Tab back and forth for each setting.

http://filebin.net/pcbrxu8wxw

Hombre if you're sure you observe a problem, it would be best if you opened a new issue.
This one is too messy and I wouldn't be surprised if some of the problems reported
here were due to having RT use a monitor profile and the output images being viewed
in an image viewer that does not support color management or was not configured properly.
Otherwise I will mark this as fixed in a day or two.

Reported by entertheyoni on 2012-11-14 23:13:19

Beep6581 commented 9 years ago
Yes, i'm sure that there was a difference when viewing the output with the same technic
as yours, with IrfanView in both mode (color managed and not managed).

I'll close this issue then, and will open a new one if i'm able to reproduce the bug.

Reported by natureh.510 on 2012-11-14 23:29:23