@maderafunk Sorry for misunderstanding the problem albeit my write up was correct.
I thought you could not actually move the slider rather than the fact that there was absolutely no correspondence between the two, pipette and slider, for JPGs!
So having set the white balance via the pipette the movement of the slider is with respect to its own starting point which has not been adjusted by the pipette selection, i.e. the slider is starting from its original reference point not the adjusted pipette selected point!
So you have an either or situation, you cannot use the slider to fine tune the pipette selection with JPGs!! Check the manual to see if it makes that clear and then raise a support request!
Ah, I understand the problem now. Yes, that’s frustrating! I wish it worked the way you propose. Unfortunately, the latest manual says only that you can use either the color picker or the slider. They clearly don’t work in tandem, and the manual should say so. I agree with raising a support request. In the meantime, a workaround would be to use the pipette to pick what will be treated as gray, close the pipette tool, export the image to TIFF or JPEG, then load that image and make fine adjustments as you want. Or, add warmth or coolness using FilmPack’s adjustable filters instead of the color temperature slider (that’s what I usually do). Not great to have to work around the problem, but hopefully not something you have to do often.
Just for completion, this is stated in the manual:
Fine-tuning the white balance of a RAW file
However you choose to initially correct your images for white balance — via pre-established settings or the eyedropper, you can fine-tune the
corrections using the Color temperature and Tint sliders. The Color temperature slider has a range of 2,000 °K to 50,000 °K, and can often
be combined with the Tint slider to remove residual colorcasts.
When you select a JPEG or TIFF file in the Image Browser to set the white balance, the RAW white balance palette changes automatically to
the RGB white balance palette, in which a simplified Color temperature slider is available in addition to the color picker. Strictly speaking, it is
not possible nor recommended to set the white balance for a JPEG or TIFF file, since the white balance has already been established by in-
camera processing. Therefore, any modification in one tonal range will produce imbalances in other tonal ranges: if we correct the midtone
greys, then highlight greys or low-key greys will inevitably suffer a slight colored hue. You can use either the color picker (eyedropper — see
above) or a dedicated slider, both available in the advanced settings (OS X), to move from cooler (blue) tones to warmer (yellow) tones and
vice-versa.
So they clearly state that possibility of fine tuning for raws, but for no reason, it has not been implemented for jpgs.
By the way, the French manual PDF has around 50MB, while th English manual has 90MB. I wonder what’s the difference, usually English sentences are much shorter than French sentences…
@maderfunk although they state that you can use one or the other, plus the fact that you shouldn’t use either for JPG and TIFF, it doesn’t state the behaviour we actually experience exactly, other than covering it somewhat obtusely by stating one OR the other!?
Neither does it state why they effectively work completely independently!?
In ACDSee you get an ‘Auto’ function and the pipette and both cause the sliders, i.e. ‘Temperature’, ‘Tint’ and ‘Strength’ sliders, to align with the ‘Auto’ and ‘pipette’ function (plus a raft of other functions)!
I’ve never been in trouble with the Law (hoping not to tempt fate with that statement) in either England or France to know!!
This must be related to the way the PDFs are generated. After I edited my copies of both the EN and FR manuals in order to fix a few quirks, they are now both as small as 11 MB.
By the way, DxO (actually, Gilles Théophile) still don’t specify a version number or a publication date for their manuals. Or it is well hidden. This is annoying.
using the slider only
I could grab it with the mouse and set it to the desired cold-warm-balance
and then after fine tune with the keyboard cursor in 10K increments
starting with the picker (also holding down + ‘hovering’) I could set the new whitepoint,
but then using the slider (also positioning somewhere) resets the picker’s setting
yes, they are independent tools (either / or)
so …
when to start with the picker to get the new whitepoint
then export as already proposed by @Egregius
(resulting in a new starting point)
activate the slider and use the keyboard cursor to fine tune in 10K increments
I did it again using the online editor at smallpdf.com (see also ilovepdf.com). Upload, possibly edit and export as compressed PDF. It took some time but the size of both files is now under 10 MB.
But exporting an intermediate jpg with additional loss of quality just for the white balance is really no proper alternative, when dxo could just implement the white balance the same way as they do for raw. It’s basically one line of code that they can copy and paste.
I’d also like to see the pipette and slider work cooperatively, but why do you think it’s one line of code or an easy fix? RAW and RGB white balancing/temperature settings are completely different by their very definition, despite being labeled similarly in the GUI.
It does not matter if the algorithms for raw and jpg are different. It is just a question of the user interface.
When you use the pipette, the algorithm will calculate a value X for the white balance correction. When you use the slider, the value from that slider will also be transformed to a value X for the white balance correction. So one value X from the pipette or from the slider would be the same, they just need to be connected in the user interface.
The line of code would be something like this:
Dear Mr Slider, please move your behind to the position that will return X.
@Wolfgang and how does that work-around work for a batch of images? It does not, as I cannot just copy the white balance from one image to the other. I’d have to repeat that intermediate exporting step for each image. I’d rather use a different software altogether that is properly designed.
I appreciate the ideas for a work around. But my intention was rather to make dxo aware of this design flaw with the hope that they will fix this, before users will abandon their software completely.
I was quickly looking for batch processing using TIFFs … there it is.
The link is about how I’ve been doing with pics for photobooks (print shop), as I needed a ‘viable’ solution (it’s more a workaround) for mass colour correction based on some softproofing, which PL didn’t offer yet. The goal was to warm up the pics, that otherwise would come out to cold.
here a snippet
>> Synchronization <<
Pictures for a print collection or photo book are (usually) taken with indivual color settings.
TIFF’s are finished files and as such contain no more information about colour temperature. Only with that it is possible to mass correct all pictures at once, with exactly the same settings
Before I exported them as JPG … I quickly went through the collection to see if it worked – and to retry with those needing an extra cure.
@Egregius Unless I have read the date wrongly that was back in April 2019!!??
Abandon hope all who enter here
The issue that they don’t even release the software with proper identification was raised some time ago! It got worse with the DxPL5 release and has never recovered.
Sadly, while an excellent product it lacks features, has long standing issues that urgently need fixes, while it seeks for new features in an attempt to try to drive up new sales. Keeping existing customers “happy” brings in some revenue, providing they are convinced that the upgrade is worth it but capturing new customers brings in more revenue!?
@maderafunk nice bit of pseudo-code, if only programming was quite that easy. Although passing the reference point to the “slider” logic and adjusting the display to reflect that “new” position shouldn’t be too difficult given that they already have some “model” code to work from!
and where did this information come from @Wolfgang?
i.e. this “area” is open and it looks as if work is going to be done for RGB images so @DxO_Support-Team perhaps now would be an appropriate time to fix this particular issue!
@Wolfgang I suspected as much which is why I had “sat” on the post (I was going to check) but then I thought what would give @Wolfgang a chance for a “cheap shot” and you just had to take it …???
