If the issue is only in the shadows you might experiment with the Shadow Tint slider down in the Camera Calibration section at the end of the right-hand panel in Develop.
If you feel there is an error in the Adobe camera profile for the X-E2 then it might be easier to communicate with some screen-shots, and perhaps a link to an example RAF using www.dropbox.com.
Yes, can you please provide screen-shots as well as the raw file+xmp so we can verify what you are reporting? Thank you for your help! Adriana. If using drop box notify me via email firstname.lastname@example.org. Thanks!
I'll post them later today.
Here are links to an image that shows the issue.
The camera was set to record RAW and JPG files.
DSCF0693.RAF - is the direct RAW file off the camera.
DSCF0693-In-Cam-JPG.jpg - is the jpg saved off the camera.
DSCF0693-RAF-to-LR-to-JPG.jpg - is the jpg export, from Lightroom 5.3 RC, from the RAF file, with defaults, nothing changed.
The Camera Calibration/Shadow Slider isn't all that helpfull in removing the magenta. The Basic/Tint slider does help. The Lightroom RAF conversion also shows a strong colored line around the edge of the main subjects lips.
Side note: The on camera settings had noise reduction set to it's lowest setting, -2. You'll notice the camera is overly smoothing skin tones. That's an issue Fuji needs to work on, in my opinion.
It looks to me this is a cast from the device the subject was holding. I was able to remove the magenta cast easily by moving the tint slider slightly to the left. I will confirm with our developers and will let you know. Thank you!
In my opinion, the X-E2 camera profile needs more work. The blue light from the handheld device screen is coloring the portion of the face toward it, yes, but the transition between that and the skin illuminated by the overhead lighting seems too abrupt, as if the blue color is being over emphasized. There is also quite a bit of blue in very dark shadowed areas toward the lower righthand corner, possibly from daylight, another device, or even internal amp-glow thermal noise. In the Fuji rendition, the transition between device-colored face and the overhead-colored skin is reasonably smooth and the shadowed area is very dark so any bluish tint isn’t discernible.
I too am bothered by the severe amount of noise-reduction applied to the in-camera JPG when supposedly the noise-reduction is set to its lowest level of -2. Obviously LR needs to have some luminance NR applied to smooth things out, but Fuji seems to be overdoing it.
I'm seeing a sharp magenta tint to skintone transition in multiple RAF files in Lightroom. Moving the tint slider shifts this sharp transition very unnaturally. The effect appears banded or posterized, many times showing up in shadowed skin areas or lips. In the link above you'll find a file (DSCF0682.RAF) that exibits the issue in the subjects lips. I'll find and post a few additional examples.
Maybe all that's needed is a better camera color profile, or maybe the issue is earlier in the pipeline. I've debated purchasing a ColorChecker and attempting the efforts to make my own profile; but I wanted to wait for the release version to see how things improved.
With one or two new additional Fuji X-Trans II sensor cameras rumored to be announced in Jan, my hope is the Adobe team will work to produce the industry leading X-Trans RAW development. These cameras are amazing, fun to use, and produce excellent images. Pair that with the joy of an Adobe Lightroom workflow, that reproduces color accuratly with the best detail possible, and I'll be a happy customer.
Below is an RGB Composite image out of RawDigger, which is dark and unsaturanted; however, using LR Auto Tone and increasing the Saturatino and Vibrance a bunch, makes the image have similar characteristics to the Fuji JPG. It may be a little oversaturated, but that is to demonstrate that the magenta doesn't overtake the skin nor is there an abrupt transition.
It is not the device he is holding.
I am having the same problem and have many images of people under artificial lighting with purple patches, with very harsh outlines, and also very bright pink lips.
Even when things look OK, adjusting the white balance in Lightroom does crazy things to the skin.
I have tested this extensivly with other cameras and other raw convertors, and the problem ONLY appears in Lightroom 5.3RC with the Fuji X-E2 for me.
Shooting teh same scene with a different camera does not have this problem, and developing the Fuji RAWs in other softwares also does not show these issues.
The device lighting, in this example, is more blue so causes a mixed lighting situation much like daylight from windows would, but Adobe's conversion of colors that are a little shifted towards the blue is very wrong. It's as if beyond a certain percentage of blue both red and blue are maxed out to pure magenta tempered with a little of the green pixels.
We are looking into this. Thank you for your postings! -adriana
Below is an example of two different Fuji X-E2 LR5.3RC issues, and at least one appears to be a demosaicking or other low-level processing error, rather than a profile error. The file comes from a dropbox link on this feedback topic:
Here is a closeup of an infant's face in _DSF0502 that shows the problems. The lefthand closeup is from RawDigger/LibRaw that looks very, very good, while the righthand closeup is from LR 5.3 RC1 and has several deficiencies:
The first issue is the abrupt transition to magenta if there is a slight shift in skintone toward the red or blue, as also illustrated in the device-lit-face picture, above, and the magenta area grows and shrinks significantly with small WB ajdustments. Here I have eyedroppered the white of the lower eye, which is a standard WBing technique.
A second issue appears to be color bleeding, in this case into the whites of the eyes from the surrounding skintone area. It is this second issue that seems like it cannot be just a camera profile issue, because the color that bleeds into the white area is different colors. To me it looks like a simplistic interpolation of the blue and red pixels across a wide area or perhaps the mixing up of green for red and blue pixels. If the corresponding JPG at the dropbox link in the feedback thread are camera JPGs, then the camera, itself, also has this problem to some extent. However, the decoding of RawDigger/LibRaw appears much better, and I'd hope Adobe could improve what they are doing to beyond what the camera does, if those JPGs are indeed what the camera is doing.
A third issue, which may be another incarnation of the first issue, is the oversaturation of reds when there is a little more red in the image. Here is shows up in the lips, as if there were lipstick applied to everyone.
These issues seem to be worse in tungsten-lit images where the red pixels are quite bright and need dimished to compensate for the color of the lighting.
Standard Bayer sensors have a 2:1 ratio of green to each of red or blue with a 2x2 repeating pattern. The X-Trans sensors have a 2.5:1 ratio of green to red or blue with a 6x6 repeating pattern so optimizations to demosaicking one do not necessarily lead to optimal results with the other. http://en.wikipedia.org/wiki/Bayer_filter
Another great example of the problem. Here is a zoom of an off camera jpg (left), and Lightroom rendered RAF (right), with no adjustments applied to either image.
Both image files are avilable here: (DSCF0525.JPG/RAF) https://www.dropbox.com/sh/emsrmvzyg4pwz3z/3es1msU-VB
That's an excellent example. The camera image seems a little too magenta, although much more even than LR 5.3 RC.
Here is the LibRaw/RawDigger conversion using As Shot WB, where the colors seem more natural to me than either Fuji or Adobe, because even if I oversaturate there is just more red, not a shift toward magenta:
Indidently, when is the next release due?
No one can say publically what Adobe’s internal timelines are, although occasionally the camera-raw-engineer Eric Chan will tell us that they’ve fixed something and it’ll be “soon” but that’s about as specific as it gets and usually there is nothing said.
I’d guess by the end of the year +/- a week or two, but hopefully not until Adobe figures out what they did wrong with the X-E2 otherwise it’ll be another 3-months for the RC of the next LR version.
If someone just made a mistake then it may be easy to fix by redoing their camera calibration or checking any camera-specific programming, but if there is something different with the camera sensor compared to the X-E1 or X-Pro1 that Adobe needs to analyze and reprogram for, it could take a while, and if Adobe isn’t quite sure about things, yet, an RC2 might be useful. People are waiting for the Nikon Df to be supported, but I’d expect that’d be straightforward compared to the X-Trans decoding. There will probably be new cameras announced in January or February, important ones, like the Canon 7D Mark II, so an RC2 might push that next release further into the future which wouldn’t be helpful, necessarily, though.
In my opinion the LibRaw conversion is better than the camera’s JPGs, both regarding color-bleeding and oversaturation of magenta, so if Adobe is only trying to be almost as good as the camera, then it is not enough.
Hopefully they can fix it, becasue not doing anything either means not buying another X-E2, or more likley using a competitors RAW processor such as Apple Apperture, Photo Ninja etc
Is there a reason that Lightroom seems a bit behind in working with the X-Trans? Smaller developers seem to have much better results such as Iridient, LibRaw etc - can't Adobe just pay those guys to help them? Or is that a totally naive way of looking at it
I am not an Adobe insider, nor have access to such, nor would I say anything if I was or did, so this is just speculation:
The X-Trans sensor has a new color layout and people had to invent ways to decode it over the last couple years.
On the legal side of things, if Adobe doesn't already employ the person with the best idea with an employment contract that says they can use whatever that person invents however they want or the best idea isn't already public-domain--meaning anyone can use it without restriction, then Adobe needs to be careful. If they happen to use an idea someone else is using then it depends on who files the patent application or copyrights the code, first. If they happen to use a method that someone else is using with an agreement that is time-limited, then perhaps in the future that other party will decide to hold Adobe hostage and require much more money for renegotiating the license. Maybe someone has licensed their method to some smaller companies but doesn't like big companies or has some personal grudge against or is a direct competitor with Adobe, so won't cooperate with Adobe on terms acceptable to Adobe.
On a technical side of things, maybe Adobe's low-level processing, that is likely perfected for the 2x2 Bayer sensor layout, doesn't lend itself to using any of the methods that have so far been invented for the 6x6 X-Trans color layout. There is an open-source group the produces source-code called dcraw (David Coffin RAW) that probably does something reasonable with X-Trans decoding, and I think I remember Eric Chan (Adobe Raw Engineer) saying that Adobe and the DCRAW people collaborated on things, but Adobe probably can't just copy and use whatever they want, or at least chooses not to for the "be careful".
On the business side of things, X-Trans is difficult, and sometimes you just hope no one cares and the need to support such a sensor will just fade away. Maybe Adobe had this initial attitude toward Fuji X-Trans, and they are still behind other companies that tried harder in the beginning. I think Adobe also was surprised by the new sensor, not having had any advanced warning, so it took them a while to get up to speed.
A small company run by a technical person can concentrate their efforts on perfecting something technical to the detriment of other aspects of their product, like the user-interface.
The Lightroom 5.3 release version appears to have fixed the problem. Thanks Adobe, images look natural.
Hmm - it's gone from a 9/10 problem to a 3/10 but the problem still occurs.
It occurs much less though, that's for sure. So obviously addressed in part - hopefully by 5.4 it will be gone entirely.
Yes, we did some work on the profile (based on feedback in this thread, and elsewhere) to improve the colors, esp. in low color-temp situations.