I understood you know how numbers are coded digitally. But my english is maybe not precise enough so forgive me if you think I insist on some details, this is just to try to be clear.
DNG is a container, like openEXR or like MOV for video.
This means it can store differents things (not all DNG files contain the same components) and it have to “describe” them with metadatas to allow to be read properly.
Usually DNG can store colors channels (and RAW) datas in :
8 bits values (for embeded jpg preview).
16 bits values (for RAW datas - because 8 bits is not precise enough and some datas would be lost).
16 bits floating points values (for some HDR related things - but forget it - not our case).
We can normalize those values between 0 an 1 (or 0 and 100%).
So 0 in 8 bits is equivalent to 0 in 16 bits and 0 when normalized.
255 in 8bits is equivalent to 65 536 in 16 bits and 1 when normalized.
And so you can easily deduce equivalence of values in between.
Any value in decimal you can read from any software “analysing” DNG (255 or 57837 for example) is a conversion from a binary value (a 8 bits, 16 bits or 16 bitsFP value for example).
So when you read values from raw datas in dng, you should get values from 0 to 65 536 in decimal since raw datas are stored in 16 bits.
If you get a value of 255 and it is the maximum possible value, either this value comes from the embeded jpg (8bits), or if it comes from the raw datas and is the maximum possible value, the software you use to analyse DNG displays them in 8 bits (converted in decimal) - I don’t know if some software do that.
This 57837 value is the brightest value found in the DNG file exported from photolab. It is read with rawdigger software, which allow to analyse RAW datas.
In 8 bits this would be equivalent to 225, and not, as you would expect, 255 for a completely burned part of the image (or 65536 in 16 bits).
This is why the DNG file should notice (in metadatas) what the brightest value is : 57837 (which is equivalent to 225 in 8 bits) and not 65536 (which is equivalent to 255 in 8bits) so that any software can read it correctly.
I’m just trying to explain what I read above. I didn’t do the test.
I did my best with my english. Hope you can understand.
Had that version too, but decided for less colour in the sky in order to emphasize the landscape.
Also thought of cloning in a few of the less overexposed parts of the sky, but decided against it because there is not much to source the clones from…and after all, I was going for the concept rather than a finished image.
Why do I see 255 (8 bits) in the same image in PL?
And is this brightest value a tag in the dng, if so how is it named? And what is the purpose of the white level tag?
Thank you really to everyone for your involvement in my topic.
At his point, you gave me a lot of solutions to get around the problem, it cool, thanks.
However, I hope that DxO will make me an answer which allow me to be back to my initial workflow.
It’s deseapointed to have to change my workflow which I used since more than 5 years only because it’s not working with my new camera.
In this hobby, I’d rather take pictures than computers.
A question worries me : Am I the only one person which has a X-T5 and use PL/LR ? I would like to know if anyone else has noticed this same issue.
Yes, I don’t get why he thinks that 57837(16-bit), which is the equivalent of 225(8-bit) is a suitable replacement for 65535 when I can lose any over-exposure markers by only dropping to 64764(16bit), which is the equivalent of 252(8-bit)
And, even more, I don’t see why on earth you would want to kludge the metadata with such a massive change in white level, which only serves to reduce the dynamic range of the image and, thus, possible contrast.
Given my findings that out of gamut levels can invoke similar problems, there is another possibility for difference between old files and new. PL6 now uses the new wide gamut colour space by default for all newly read files and you might be seeing you older files in the old AdobeRGB colour space.
@Merlinx63 It would seem that your problems started with the different camera, which makes me wonder why you would assume it is PL at fault. The logical sequence is to examine the files from the two cameras first.
Would you like to make available an image from your X-H2S, so we can compare the two to see what the problem might be?
He told this value (57837) is the value of brightest color in the DNG exported by photolab when “analysed” with rawdigger. This is what I understood.
The highest value in the overexposed sky so.
And metatdata which “describe” this brightest color seemed wrong.
So he replaced it by the value read in rawdigger (57837) and so, when raw brightest value and metadata describing brightest value matched, DNG was read properly. No majenta in overexposed zone.
Again, this is what I understood.
Or you can turn it in the opposite way :
the brightest color found in the dng (57837) when exported by photolab is wrong. it should have been 65535.
And the metadata describing it is right (I think - I didn’t read those datas myself).
did you see it when looking at the DNG file or the RAW file ?
noname saw this value in the DNG expoted file. When reading it in rawdigger. Not photolab.
There are other differences but, just looking at those above, I would say that there is a possibility that some of those tags might well influence how different software interprets the highlights in your two cameras.
If it is not a tag, then it is a product of the program. It’s not in the file.
When I export to disk the file and open it again there is no problem. And the exported dng contains a linear rgb image, meaning all the pixels have a fixed value. Non linear editing leaves the extreme value untouched.
I can’t be of any help since I don’t own LR.
It comes down to how good the highlight recovery algorithms are. I know LibRaw has a choice of 10!
I’m set up for Sony and Capture One Express for Sony is the best for me. Suggest you look at Capture One Express for Fujifilm (its free) and send your problem dng’s there then a tiff to LR or whatever. Use a Linear Response curve in C1 and p[lay with highlight sliders etc. Of course it won’t work if all channels are blown out but if its only some it goes well.
PS My Sony camera has zebras that indicate over exposure in the view finder. Doesn’t fujifilm have something like that? Saves a lot of messing around.
On my G80 there are based on the oocjpeg’s calculations and effectively underexpose by two stops if you react to those appearing stripes and lower exposure til they are gone.
I tested it and white flowers gone of white point.
The panasonic has also idyn. Which is originally ment for oocjpeg’s to enhance dynamic range. But as Side effect i use it as automated clipping protection.
It lowers exposure, shuttertime, 1/3 2/3 or 1 stop when it saturates to much in a high dynamic scene.
I can’t remember when i tested it if the lowering is for rawlevels or jpeg levels as anti clipping but it’s more accurate then the zebra striping.
I may test again, sun is shinning so…
update:
what Idyn does is screening your image for dynamic range and when it exceeds the capabilities of the camera it under expose in 1/3 2/3 1stop in order to keep detail in highlights (it’s around +3ev(white chairs) on the highlights in this example so clipped or near clipped…)
and in the ooc jpegs it lifts shadows to have more detail and exposure in the under exposed area’s.
quite smart.
it shuts off when i delibrately over expose so it is a lazy highlight protector but inside the rawfiles dynamic range and not -2stops jpeg modes as fare as i can tell in this short test.
in order to have the same “look” as the ooc-jpeg i need to set EC at 2.00 (DNG) and highlight and contrast hightlights at -65 note i didn’t repaired overexposure in the ooc jpeg. and at 2.56EC and -70 i got exported jpeg in srgb
All and all zebrawarnings are for ooc-jpegs and intelligent dynamicrange control which more camera’s has then panasonic alone, has positive effects on your rawfile’s too.
if you like to see for your self: the rawfiles and oocjpeg’s
and Ires is intelligent resolution improvement. which is the same as the in silkypis available [natural sharpening](file:///C:/Program%20Files/ISL/SILKYPIX%20Developer%20Studio%20Pro%2010%20for%20Panasonic%20English/manual/man0006.html#sharpening-adjustment)
this has no effect on a raw file but has a flag so silkypix can read that setting to.
Photo style/Camera color
“Photo style/Camera color” is a profile to reproduce color creation by Panasonic digital cameras, and user can select this when you take RAW data by one of applicable cameras.
When you select “Photo style/Camera color,” “Color representation” will be changed to dedicated item “Photo style/Camera color.” You can select available photo style or “Camera color” which represents basic camera colors.
You can see digital cameras which are capable of “Photo style/Camera color” in “Supported cameras list.”
So there are more flags in the rawfiles DxO can’t use. Or not want to use.
camera styles in color vivid natural monochrome and settings for ooc-jpeg as idyn ires and corrections as lens issue’s vigentting and such. ( which dxo aplied twice because they didn’t read the flag vignetting done of panasonics rw2
@Merlinx63 Hello, we spotted the problem for Fuji X-T5. We will fix it before the end of 2023, I don’t have a specific date to provide. Thank you for your understanding
@Merlinx63 i was searching (out of interest) to see if your Fuij’s have the same kind of set and forget idyn-mode.
(It has nothing to do with your purple in the highlights but well it could be to your aid for avoiding it all together )
what i found interesting is it’s depending on some ground clearens from base iso.
i didn’t looked for the why but normally higher isovalue means lower camerasensor DR.
So it’s a bit contradictive.
it seems not to be auto on/off so no set and forget.
further search popped up this
you have automodes.
What you could do is set up a camera on a tripod in a sunny day with some high dynamic scenery.
set manual mode ss and Aperture see if those options arn’t greyed out (then it won’t work in (msap)manual mode) exposure accoording how you would/check with autoexposure mode what the camera would do.
then shoot -1ev -1/2 0 +1/2 +1 with non of the DR aid’s active.
same sequence with the 100/200/300DR on auto (that seems to be a idyn auto modes for rawfiles)
(i think it also raises isovalue when it needs so see if that is also the case.)
then same sequence in that other dynamic prio in auto modes.
And for cross reverence all 6 manual steps in the menu’s.
See what it does and how it interfere in the normal DR/exposure of the scene.
maybe you end up with a nice auto protection for highlights in high dynamic scenes.
like ESP/ASP in your car. it only kicks in when it detects a “problem” and sleeps when it’s all good.
)
)
