rschaub

all of this would be possible with procedural textures, if there was a way to access color values at a certain coordinate.
I'm not sure if this is already possible, but I found no way to do that. Something like
R[x+1,y] - R[x-1,y] // access color channel R with relative offsets of (-1, 0) and (1, 0) would open up a whole world of possibilities for procedural textures.
This would require access to the current coordinate (x, y) if R[x,y] samples the channel at absolute coordinates.
 

Hi all!
I just experienced the same problem (white color in photos or color swatches has a yellow tint) and have a solution (or rather a workaround) that works for me and possibly for others as well.
Background
I have a Windows 7 machine and just upgraded my graphics card from AMD to Nvidia and noticed that Windows color management automatically assigned a color profile to my monitor (I don't really know where the profile came from - I have never attempted to calibrate my monitor). I remember manually deleting the assignment before (with my old AMD graphics card) because I had a yellow tint in Publisher. Now the profile is back and with it the color tint - in all color managed application. After deleting the profile assignment again, the yellow tint vanished for all color managed applications except Publisher. This problem occurs in all my tested versions (1.7.1 and 1.7.2).
Workaround
The workaround which works for me is to not only delete the profile assignment, but the profile itself (i.e. the physical file in which the profile is stored). Only then white is white again in Publisher. It seem Publisher does not correctly handle Windows color management settings and employs its own logic when assigning device profiles - interestingly this logic seems to differ depending on the graphics card manufacturer, but I'm just guessing. In this regard Publisher acts differently than all my other color-managed applications (like Photoshop, Lightroom or even the Windows built-in image viewer).
Step-by-step (on-screen text translated from the German Windows version, your text might read slightly different)
This is a step-by-step solution that works for me, YMMV. If you have calibrated your monitor using some hardware color calibration device you probably should not carry out these steps, but I guess in this case you don't have the problem to begin with.
Open Windows Color Management in the Control Panel. Select your monitor on the first tab ("Devices"). If your problem is similar to mine you'll see a profile assigned to your monitor in the box below. Check the "Use own settings for the device" box, click the assigned profile and click "Delete". This will delete the assignment, but not the profile itself. Check whether this solves your problem. If it persists continue. Open the "All Profiles" tab and look for the profile that was assigned to your monitor. Optional: Back up the profile file: Open a Windows Explorer window, navigate to C:\Windows\System32\spool\drivers\color and copy your monitor profile from step 5 to a safe place. Select the profile in the color management window and click "Delete". This will physically delete the profile file (probably after asking for elevated rights). For me this step failed, so I manually deleted the file from the folder in step 6. Cross your fingers and check whether this solves your problem.

To answer my own question:
 
The problem with visible dithering in theoretically smooth gradients lie with the application's performance settings.
 
Edit -> Performance -> Dither gradients
 
Unchecking this option will make gradients perfectly smooth :D .
Having the option checked will result in the above mentioned behavior.