Closed Beep6581 closed 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
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
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
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
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
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
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
What's your working profile?
Reported by entertheyoni
on 2011-11-30 20:47:26
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
Yep, happens with every output profile.
Reported by keith.reeder
on 2011-12-01 18:12:10
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
I notice a slight difference too.
http://min.us/mbiGQQFEN7
Latest RT.
Reported by entertheyoni
on 2011-12-01 23:03:09
Can repro, too. Output is lighter than preview. Bad bug :-(
Reported by oduis@hotmail.com
on 2011-12-02 07:13:54
Accepted
It happens with Neutral/Auto Levels/RT_sRGB too, Yoni.
Reported by keith.reeder
on 2011-12-02 19:30:57
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
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
Still happening in 4.0.6.4 for me.
Reported by keith.reeder
on 2011-12-15 19:27:58
Update - this seems to be fixed in the latest "official" release.
Reported by keith.reeder
on 2011-12-17 10:12:06
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
Yep, I was wrong - it's still happening.
Reported by keith.reeder
on 2011-12-17 13:51:52
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
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
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
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
Reported by natureh.510
on 2012-01-11 09:51:49
Started
Reported by natureh.510
on 2012-11-14 00:24:53
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
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
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
Fixed
Originally reported on Google Code with ID 1133
Reported by
keith.reeder
on 2011-11-30 08:46:28