Closed Beep6581 closed 9 years ago
With input profile set to 'No profile' it's black. With input profile set to 'use embedded,
if possible' it's blue.
Ingo
Reported by heckflosse@i-weyrich.de
on 2013-12-19 13:57:18
then you get a different behavior than me... strange... I have black for both no profile
and embedded. If I select a custom small profile (adobe rgb for example) the blue appears
again.
Probably quite easy to find, just follow the pipeline and see where the clipping occurs...
but no hurry to fix it.
Reported by torger@ludd.ltu.se
on 2013-12-19 14:10:19
Accepted
I also have black for both no profile and embedded.
On win vista 32bit
Branch: default
Version: 4.0.11.198
Changeset: cf0910c613c4
Compiler: gcc 4.6.1
Processor: generic x86
System: Windows
Bit depth: 32 bits
Gtkmm: V2.22.0
Build type: Release
Build flags: -m32 -mthreads -mstackrealign -mtune=generic -fopenmp -mwindows -DNDEBUG
-msse2 -mfpmath=sse -O3
Link flags: -m32 -mthreads -static-libgcc -Wl,--large-address-aware,--verbose -mtune=generic
-mwindows -s -O3
OpenMP support: ON
MMAP support: ON
Reported by iliasgiarimis
on 2013-12-19 15:13:23
Reproduced.
I saw this with a blue bar the first time I opened the dir containing the image http://i.imgur.com/1kHc3Pq.png
As soon as I maximized the window, the blue bar disappeared and its red, green, black.
Input profile none, working sRGB: RGBlue
Input profile none, working Adobe RGB: RGBlue
Input profile none, working ProPhoto: RGBlack
Input profile none, working WideGamut: RGBlue
Input profile none, working BruceRGB: RGBlue
Input profile none, working BetaRGB: RGBlue
Input profile none, working BestRGB: RGBlue
Input profile embedded, working whatever: RGBlack
Sometimes the thumbnail matches the preview, sometimes it does not!
Branch: default
Version: 4.0.11.202 (33efb0e6d996 + 2137-HLRecovery.patch)
Changeset: 165da6c5558d
Compiler: cc 4.7.3
Processor: undefined
System: Linux
Bit depth: 64 bits
Gtkmm: V2.24.4
Build type: Release
Build flags: -Wno-unused-result -Wno-aggressive-loop-optimizations -march=native -fopenmp
-O3 -DNDEBUG
Link flags: -march=native
OpenMP support: ON
MMAP support: ON
Reported by entertheyoni
on 2013-12-19 16:12:38
And now my K10D shots in fluorescent lighting with a custom DCP (a crappy one) are affected
http://i.imgur.com/BFVzBMp.jpg
Slim chance anyone will solve this for 4.1 so not setting as blocking, but its quite
serious.
Reported by entertheyoni
on 2014-03-20 19:43:09
I created three new DCP profiles from three Passport chart shots taken in the same place
and lighting as the shots I apply them to. Each of them displays the blue-black bug.
http://i.imgur.com/Qy1aUrr.jpg
http://i.imgur.com/vJv9Smn.jpg
Reported by entertheyoni
on 2014-03-20 21:03:16
I have also this problem when "lab adjustment/avoid color shift" is on.
Reported by gaaned92
on 2014-03-20 21:24:01
Here's a patch. It's kind of a hack, but solves the problem in all cases I know.
Reported by heckflosse@i-weyrich.de
on 2014-03-26 19:13:53
PatchSubmitted
And it works perfectly: http://imgur.com/a/BTMeg#0
Reported by entertheyoni
on 2014-03-26 19:42:20
1-RGB image
If I click on "lab adjustment/avoid color shift" with "use embedded profile if possible"
Blue is still black in the RGB image.
With no profile : OK
2-with Blue saturated photo using auto matched camera profile
Ok for all working color space except widegamut.
So for me it's ok as I only use RT on real photos.
Reported by gaaned92
on 2014-03-26 22:23:00
Hi André, do you mean with rgp-prophoto.tif?
If I choose "lab adjustment/avoid color shift" with "use embedded profile, if possible"
at that picture, blue is blue.
I confirm that there's still an Issue when using 'wide gamut'
Ingo
Reported by heckflosse@i-weyrich.de
on 2014-03-26 22:37:00
Yes rgb-prophoto.tif : strange! "lab adjustment/avoid color shift" with "use embedded
profile, if possible" at that picture, blue is black.
I checked the patch is applied. I will rebuild tomorrow to be sure.
Reported by gaaned92
on 2014-03-26 23:12:35
Have you set a monitor colour profile set in preferences?
Reported by heckflosse@i-weyrich.de
on 2014-03-26 23:28:21
Neutral
Unpatched:
----------
rgb-prophoto.tif
Preview matches thumbnail.
Setting "Saturation -1" fixes it.
Turning off "Avoid color shift" fixes it.
Both No Profile and Use Embedded are black.
Real photo: saturated-blues-led.pef
Preview matches thumbnail.
Setting "Saturation -1" fixes it.
Turning off "Avoid color shift" fixes it.
No Profile is ok, Camera Standard is half-bad, auto-matched is completely bad.
Patched:
--------
rgb-prophoto.tif
Thumbnail is ok, navigator is black with a blue line, preview is black. http://i.imgur.com/C5LSPZD.png
Setting saturation -1 fixes the preview and navigator, but the blue is a bit darker
on the thumb. http://i.imgur.com/0AHJI6e.png
Setting saturation -2 to -8 and only the thumb's blue goes lighter, the preview and
nav are unaffected. http://i.imgur.com/KICqQi1.png http://i.imgur.com/C93JiHI.png http://i.imgur.com/p3lCaYe.png
With No Profile, preview and nav are ok, thumb is darker blue as in the -1 screenshot.
With Use Embedded, thumb does not change (still darker blue) but preview and nav
are black.
Real photo: saturated-blues-led.pef
Thumb, nav and preview match, all are ok.
Every saturation change is reflected in all three.
All working profiles are fine including wide gamut: http://i.imgur.com/zT8BliU.png
http://i.imgur.com/4Cr7gXo.png http://i.imgur.com/wBlsXJB.png http://i.imgur.com/RgkQbsx.png
I have my own icc set for the Monitor Color Profile. I also tried turning it off and
reloading the photo, and Wide Gamut was still fine. So on my end the patch works well
for real photos.
Reported by entertheyoni
on 2014-03-27 08:18:51
Committed to revision e3af8d0b602f
Reported by heckflosse@i-weyrich.de
on 2014-03-27 11:55:03
FixedPendingConfirmation
Just FYI, maybe LCMS' flag cmsFLAGS_GAMUTCHECK is involved. Is set to on, the out of
gamut pixels are rendered to a particular color.
Reported by natureh.510
on 2014-03-27 12:30:47
Hombre, I saw that too, while searching for the reason of the bug in web. But it's not
set in RT.
Reported by heckflosse@i-weyrich.de
on 2014-03-27 12:45:56
I don't really know how to check whether my LCMS was built with that. It's not in my
package manager's build script, but that doesn't guarantee it wasn't set somewhere.
Reported by entertheyoni
on 2014-03-27 12:46:40
It's a parameter to the cmsCreateTransform function used in RT. As these flags are set
by a bitwise or of several flags, skipping this flag means that the corresponding bit
in the mask is zero and so it's disabled.
Reported by heckflosse@i-weyrich.de
on 2014-03-27 13:00:35
Reported by heckflosse@i-weyrich.de
on 2014-04-04 22:51:40
Fixed
Originally reported on Google Code with ID 2141
Reported by
torger@ludd.ltu.se
on 2013-12-19 12:03:19