Strange RAW file import

I have a strange behavior when importing RAW files. The original file comes from a Sony NEX-5 with manual lens. The upper border area is of interest.

In the Microsoft Photo Viewer or XNView, the upper area of the original RAW file is displayed as

After importing without active corrections, the Photolab editor displays

and the JPG Export displays

What could be the reason for this? Does Photolab manipulate any parameters during import that I have no control of?

Any RAW image contains a JPEG preview image. If you use anything other than a RAW editor, you will only see that JPEG.

On the other hand, PhotoLab demosaĂŻcs the RAW data and presents that constructed image. Exporting takes the processed image and writes it to the preferred format.

BTW PhotoLab doesn’t import images, it just either directly displays non-RAW images or it simply shows an interpretation of a RAW image

the demosaicking artefacts from DxO PL in your example… do you have a raw file to share ? unless your example was a photo of your monitor’s screen

XnView has option to display results of it’s own raw conversion instead of “that JPEG”


@noname
What you show now is that different converters might give different results.
@gserim
The first picture in Microsoft Photo Viewer is the thumbnail in the raw file. If you don’t see any differences between Photo Viewer and XNview than you see the same thumbnail. The camera shoots in raw but also converts that raw to a RGB image and save that as jpg. It uses the settings in the camera. You can play with that and see the differences. Most visible if you set the camera to monochrome. In Photo Viewewr you’ll see a monochrome picture, in PL a colour picture
In PL Viewing conditions and exporting conditions might not be the same

George

PS
It’s not the thumbnail but the embedded jpg. So in the raw file are stored the raw data, a thumbnail in jpg and an embedded larger jpg. With Nikon that last one is full size. I don’t know what you have.

PSPS
Where did you get the PNG from?

All PNG’s are Screenshots.

Following your advice, I have looked at the RAW image in the Sony Editor and in RawTherapee - they look similar to the PhotoLab image. So it must be the camera sensor or the lens. The sensor works fine with other lenses and so does the camera. Other photos with the lens don’t seem to have the problem. Hmm, then it could probably just be the shooting situation. If I remember correctly, perhaps a particular flare could be the cause. It’s a pancake without a lens hood. I’ll have a look at that when I take the next shots. Thank you very much for your support.

How can I upload the raw file?

I show that XnView can display NOT ONLY embedded JPG ( responding to an improperly formulated statement “if you use anything other than a RAW editor, you will only see that JPEG”) - the rest is your own imagination …

IrfanView has the same CameraRaw plugin. I don’t know why to use it. Just demosaicing without any correction.
By the way, when you use it you use a raw editor. Well, half way.
@gserim didn’t see any difference between Photo Viewer and xNView so he viewed it under the standard conditions: the embedded jpg.

George

Thanks for the tip, I see the irregularities in the RAW image after changing the setting.

It is interesting that the internal camera software corrects these zones for the embedded JPG. What kind of correction could this be?

Look in your camera settings. With nikon it’s called picture control. I believe you have a sony.
From my camera: sharpening,clarity,contrast,brightness,saturation,hue.

George

My Canon cameras and my Sony a6400 are configurable in this aspect. The NEX-5 only has simpler options - creative modes etc. Everything is deactivated, including the corrections for long exposures. I only use it for manual lenses, which is why the lens corrections should not be effective. But maybe there is a basic correction?

if you think there is a problem with raw conversion in DxO software OR with raw file itself please share the raw file ( and ideally .DOP file too if you think DxO is the problem )

DSC03518.ARW (14,3 MB)

Here it is. Upload was rejected yesterday.

yes, it seems - with just a quick look , no deep diving - that DxO PL7.2 does indeed creates demosaick artefacts ( “NO CORRECTION” preset applied, to make sure )

using AI/ML demosaick paired with DP-whatever NR also leads to artefacts ( exported TIFF and viewed outside DxO PL )

Please file a bug report with DxO ASAP so that have something to do on NY eve :innocent:

PS: ACR, C1 do not show such artefacts

OK, here is the reason for a bug… as we all ( I am being generous here ) know maze artefacts are related ( in most cases ) to so called green channel disbalance ( in DNG exif tag parlance 0xc62d BayerGreenSplit - that tag you can see upon conversion from raw to DNG as Adobe shows what it thinks/knows that parameter must be during demosaick ) …

apparently wizards of DxO do not pay attention to that situation with 2 green channels with this camera model ? if I convert that .ARW to DNG and alter BayerGreenSplit tag in DNG say to zero then even ACR will give me the artefacts in that same area in the frame where DxO produces similar artefacts on original .ARW ( because working with DNG ACR will honor DNG tags and here we have explicit tag saying what to do … and DxO yet again ignores DxO tag if we restore it back to 250 value, that at least shall hint a normal software that there is a need to account for the situation with 2 green channels during demosaicking - that goes to DNG support which is lacking ) …

so Adobe developers knew to account for that matter when dealing with original raw files from that camera model and whoever was writing the code in DxO did not

https://helpx.adobe.com/content/dam/help/en/photoshop/pdf/DNG_Spec_1_7_0_0.pdf ::

BayerGreenSplit
Tag 50733 (C62D.H)
Type LONG
Count 1
Value See below
Default 0
Usage Raw IFD
Description
BayerGreenSplit only applies to CFA images using a Bayer pattern filter array. This tag specifies, in arbitrary
units, how closely the values of the green pixels in the blue/green rows track the values of the green pixels in
the red/green rows.
A value of zero means the two kinds of green pixels track closely, while a non-zero value means they
sometimes diverge. The useful range for this tag is from 0 (no divergence) to about 5000 (quite large
divergence).

PS: can you make a shot ( and share a raw file ) of some flat uniform “white” surface with the camera and the same lens filling the whole frame ( ideally uniformly illuminated - this like white paper under some decent light ) … it seems RawDigger demosaick does produce such artefacts too so they ( one of the authors ) asked for such raw file to see if they can possibly investigate further and possibly fix the matter in their software… thank you !

From what I can see, you’ve zoomed in more on the Photolab image? And AFAIK Photolab does its noise correction after you export it. So I assume your JPG export has some noise correction applied but the PhotoLab editor hasn’t.

7.2/Win :slight_smile: … ( “no correction” preset )