Hi Kofa
thx for this excellent hint - i was not aware of the fact, that Capture NX and Studio NX is already processing before I even have started to process
Hi Kofa
thx for this excellent hint - i was not aware of the fact, that Capture NX and Studio NX is already processing before I even have started to process
Wow - Looks much better
Well, itâs called a raw file for a reason
Read Eek! My Raw Photo Looks Different than the Camera JPEG
You bought an expensive camera to get exactly this: access to the raw data to bring out something the in camera jpg processor doesnt give.
If you check out the Play Raw category here, youâll see in how many different ways a photo can be developed â often completely altering the mood.
I also enjoy @s7haboâs âEditing moments with darktableâ series, for example here is the latest instalment:
I think the true question here is: what makes you believe NX Studio holds some kind of ground truth ?
Because it does not. Every software has its own interpretation of the non-image that is a raw photograph.
Donât be the grumpy old wizard @Chris2205 simply didnât know what a raw file was, but that misunderstanding has been cleared above. Everyone has to get started somewhere.
Maybe a question on the side.
Maybe this is the default rendering of darktable (since yes, no raw converters are the same. Some try to get close to what the camera does, some do not bother :))âŚ
⌠but maybe something is wrong in the settings here. Giving your raw makes sure we can compare to how it looks out of the box on our end.
As a hint, in a modern workflow, if white balance module is set to âcamera referenceâ than the âcolor calibrationâ module must be enabled (and in one of the Illuminant settings is a "as camera shotâ.
This should be the default but maybe something went wrong there.
If color calibration is disabled, white balance must be set to something ârealâ :).
Iâm guessing here, but the way the white balance looks of, reminds me when white balance is set to camera reference without enabling color calibration :).
sigh again I only see a small discussion and start a reply and then 25 other replies appear. Kofa already gave an answer and came to the same - or a better - conclusion :s.
With respect for the expertise here, I found your âEek!..â article helpful but I actually like most of my cameraâs JPEG profiles and do save a RAW+JPEG or Fine+RAW (as the setting is called in my camera). If I desire a particular JPEG version and save in just RAW, then the camera is not going to embed the JPEG version I want. Is it? And if itâs not, then have I wasted space saving what I want? Perhaps itâs time to re-read my manual.
If Iâm using RAW=+JPEG, my Nikon cameras will make the embedded JPEGs and the +JPEG with the same Picture Controls. Same render.
Now, check your image sizes, as Iâm not sure embedded preview JPEGs are the same image resolution, (width, height) as the saved JPEG file. That might make a difference in your decision.
$ dcraw -e filename.CR2
or in Windows with dcraw.exe in the same folder as your raw file:
dcraw.exe -e filename.CR2
Starting point with default settings
ART (let it use AM film curve)
Hi
Your idea regarding color calibration helped a lot - thx for that.
Is in dt a possibility to set âas camera shotâ as default. The default setting seems do by âdaylightâ
br
chris
If you use the modern wb in preferences then it reads your exif data and extracts WB info. I think at least for me initially you are on as shot. It will show daylight as the illuminant (in many cases or if non daylight it will show custom) but if you change to as shot it wont change the WB âŚ
Like priort says, if your workflow is set to âmodernâ color, new pictures should get the white balance module enabled and set to âcamera referenceâ, and have the color calibration module enabled to a âset as shotâ setting, giving you a as-shot starting point.
Pleas note that a module can be âresetâ, and can be reset to âauto defaultsâ. So if you mess around and reset the color calibration, there is a chance that âresetâ will not get you back to the starting point, but âreset auto defaultsâ will. Also, you can use the history list to go back.
Somewhere in the settings is an option for âdisplay referredâ or âscene referredâ. Underneath that is an option for âmodern color workflowâ or something similar.
I recommend using it, but remember to leave the old white balance module set to âcamera referenceâ and then use the color calibration module for white balance duties.
So ik guessing you used an old xmp file / setting / style for a picture, or you accidentally reset the color calibration completely to defaults, removing the âas shotâ default mode.
Note that as shot in camera and daylight can represent the same values:
Set to as shot in camera:
After resetting the module (sets D daylight):
Itâs still a D (daylight) illuminant with 4020 K.
Switching to custom after the reset (which set daylight):
Switching to custom after setting as shot in camera:
Interestingly, thereâs a tiny change in the histogram between as shot in camera and reset to daylight:
Overlaid in the Gimp with difference blending (and then stretching the histogram):
Or zoomed in:
I found the same but in the image I tested it was noted when going from the initial setting of daylight as determined when the module was activated to as shot. Then after that toggling back and forth between them there was no change triggeredâŚ
Note that not all settings can be expressed perfectly by all illuminants. So often you start on one, if you then switch illuminants, DT tries to convert your current value to a value that can be expressed by the new illuminant. This works âclose enoughâ but itâs never 100% perfect (what isâŚ).
So when you have value A in âcustomâ illuminant , and you convert it to daylight illuminant. It turns into value B, there is a change, a rounding error. Because A was a value that doesnât exist in daylight. B does.
If you now select the custom illuminant again, it converts value B into custom. But custom can represent all values, so there is no rounding error or loss here. This gets value C.
If you now switch back to daylight illuminant again, the conversion can be done perfectly, because that value exists. So you get a perfect B back. So if you now keep on switching between those two illuminants, there is no loss or rounding error, so you also get no slight change in the histogram.
This is all not something to be worried about or even remember when youâre making changes to pictures.
But setting white balance means setting a hue (over simplified) and the color calibration module goes to work with your selected hue in the space/model/illuminant that is selected.
As aurelien described in his introduction to this module, using âtemperatureâ and âtintâ is a real restricting way of picking a hue, and not all colors can be selected (his words were stronger :P).
So when you flip between modes and illuminants, itâs constantly taking the hue that is selected, and converting it - the best it can - to the new illuminant and mode. There can be very slight differences in the results.
According to the manual (https://www.darktable.org/usermanual/3.6/en/module-reference/processing-modules/color-calibration/#cat-tab-workflow):
Switching from any illuminant to custom preserves your settings entirely
With the raw file posted in this topic, switching from a reset module (daylight) to custom does introduce a small change (darktable 3.6.0 on Windows, and also yesterdayâs master on Linux).
I found this sample image really interesting because it looked so much better with no color preservation. So I run off to the user manual to read up on these options for preserve chrominance and this is part of what was written there âif you choose ânoâ in the preserve chrominance parameter. This value may yield seemingly âbetterâ results than the other values, but it may negatively impact later parts of the pipeline, for example, when it comes to global saturation.â
There are just so many ways to approach image editing in DT and that is what I love about it.