Wrong black level for Panasonic DMC-G81

[heckflosse]

When inspecting the raw file from this comment using demosaic set to 'None' there are raw values < 0. For example at x=1236, y=771 the raw value is reported as G=-26 I guess this is caused by a wrong black level. @iliasg could you have a look at this file?

[ff2000]

I have some more files that show negative values if needed.

I had a closer look because the linked RAW file was before I had my first issue with this sensor - it was replaced later in 2017. But negative values also show up in files after the replacement.

[iliasg]

@heckflosse Ingo, sorry for the delay, I just recieved back a "crashed" PC

There are a lot of pixels with values lower than the BL=143 in this file .. so I guess the values reported are correct. I don't know if this (showing the below BL values) is intentional .. but I think it's usefull for geeks like me ;) BTW when we use deosaic "none" .. what's the formula for scaling the navigator reported values in RAW 12 or 14 bit values ?.

[heckflosse]

@iliasg These files have zero_is_bad = true, means pixels with value zero will be interpolated from neighbouring pixels, but not pixels < zero... The values reported below navigator are taken from the scaled rawdata and divided by scale_mul, which in this case is scale_mul:[11.211660 7.139764 16.650152 7.139764]

Imho the problem is, that we have negative values in rawdata which then are scaled in the wrong direction using scale_mul. Shouldn't we clip this values to zero?

[iliasg]

@heckflosse Ingo, I misunderstood :(

Do you mean that the zero valued pixels escape some part of the normalization-scaling applied on the normal pixels ?. I was talking about raw values 0-4095 where there are thousands of pixels with values lower than the BL = 143. Most of the below BL pixels are in the range 15-143 . But some (around 30pixels on each channel) have value = 0 which is an indication of bad pixel and should be corrected by the "zero_is_bad" algorithm .. after this correction all values are in the 15-4095 range and any further operation is equally applied on all of them .. this is my thought about what should happen ..

[heckflosse]

@iliasg you're right. The zero_is_bad algorithm is called before black level subtraction and correctly finds the bad pixels. After the correction all values are in the 15-4095 range. But then the black level will be subtracted which leads for example to a value of -128 for a pixel which had value 15 before. Shouldn't this negative values be clipped to zero?

[iliasg]

@heckflosse Ingo, some say no (John Sheehy, a respected member at Dpreview forums is proponent of this) .. John in numerous posts last decade, says the clipping must occur at the last stage of converting to RGB .. i.e in RT just before conversion to the working space .. of course some things get complicated this way (raw autoWB ??) .. maybe we should invite him to expose the worflow he has in his mind (and privetelly follows for his conversions)

Is this happening in RT only lately ? .. after the unbounted process ?

[heckflosse]

@iliasg It's already in 5.3

[Thanatomanic]

I cannot replicate the issue with some raw samples from here: https://www.extrahw.com/panasonic-lumix-g80-g85-review/104-6 Files look fine to me, no clipped or strange pixels.

Closing for now...