Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pure prophoto blue rendered black #2125

Closed
Beep6581 opened this issue Aug 11, 2015 · 20 comments
Closed

pure prophoto blue rendered black #2125

Beep6581 opened this issue Aug 11, 2015 · 20 comments
Assignees

Comments

@Beep6581
Copy link
Owner

Originally reported on Google Code with ID 2141

The attached artificial tif has three fields, pure red, green and blue, and then a prophoto.icc
embedded.

Sample values in the 8 bit file is 255

By some unknown reason the blue field is rendered as black. Tested on Linux and OS
X. 4.0.11.200 and 4.0.11.54.

What probably happens is some sort of strange clipping when moving to working space,
which I had set to prophoto too.

The problem is quite theoretical as these sort of colors don't appear in real photos,
but someone might want to look into it as there is probably some slight problem in
the color transformations somewhere.

Reported by torger@ludd.ltu.se on 2013-12-19 12:03:19


- _Attachment: [rgb-prophoto.tif](https://storage.googleapis.com/google-code-attachments/rawtherapee/issue-2141/comment-0/rgb-prophoto.tif)_
@Beep6581 Beep6581 self-assigned this Aug 11, 2015
@Beep6581
Copy link
Owner Author

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

@Beep6581
Copy link
Owner Author

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

  • Status changed: Accepted

@Beep6581
Copy link
Owner Author

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

@Beep6581
Copy link
Owner Author

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

@Beep6581
Copy link
Owner Author

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

  • Labels added: Priority-High, Component-Quality
  • Labels removed: Priority-Low

@Beep6581
Copy link
Owner Author

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

@Beep6581
Copy link
Owner Author

I have also this problem when "lab adjustment/avoid color shift" is on.

Reported by gaaned92 on 2014-03-20 21:24:01

@Beep6581
Copy link
Owner Author

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

  • Status changed: PatchSubmitted

- _Attachment: [issue2141_00.patch](https://storage.googleapis.com/google-code-attachments/rawtherapee/issue-2141/comment-8/issue2141_00.patch)_

@Beep6581
Copy link
Owner Author

And it works perfectly: http://imgur.com/a/BTMeg#0

Reported by entertheyoni on 2014-03-26 19:42:20

@Beep6581
Copy link
Owner Author

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

@Beep6581
Copy link
Owner Author

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

@Beep6581
Copy link
Owner Author

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

@Beep6581
Copy link
Owner Author

Have you set a monitor colour profile set in preferences?

Reported by heckflosse@i-weyrich.de on 2014-03-26 23:28:21

@Beep6581
Copy link
Owner Author

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

@Beep6581
Copy link
Owner Author

Committed to revision e3af8d0b602f

Reported by heckflosse@i-weyrich.de on 2014-03-27 11:55:03

  • Status changed: FixedPendingConfirmation

@Beep6581
Copy link
Owner Author

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

@Beep6581
Copy link
Owner Author

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

@Beep6581
Copy link
Owner Author

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

@Beep6581
Copy link
Owner Author

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

@Beep6581
Copy link
Owner Author

Reported by heckflosse@i-weyrich.de on 2014-04-04 22:51:40

  • Status changed: Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant