buda-base / scam

segment and crop anything
Apache License 2.0
3 stars 1 forks source link

adjustments to raw opening for post processing #56

Closed eroux closed 6 months ago

eroux commented 7 months ago

for post-processing (only), when the raw file is 16-bit deep, we actually have to keep the 16-bit as sometimes the histogram is confined to 10 values when mapped to 8-bit, which is not enough to do proper post-processing. One issue is that the raw opener currently doesn't use the PIL modes like I;16, etc.

eroux commented 7 months ago

from @jimk-bdrc

That's a good argument for not post-processing raw at all. Dump it into a TIFF, and process that - or only process it when making derivatives.

my answer:

to some extent yes, two counter arguments:

jimk-bdrc commented 7 months ago

to some extent yes, two counter arguments:

  • that basically multiplies the size of all the archive folder by 2
  • when we have information such as a color card, having "correct" archive files is much better as that means there's no need to fix the white balance, exposure, etc. at derivation time, which essentially makes the derivation impossible to automate

Excellent points! I'd only say that the multiply factor is 2 only if we decide to keep the RAW files. I went looking for a discussion of that - I couldn't find a resolution, but it led to a wider discussion. One intersesting output is Automated_Preserversion_The_case_of_Digital Raw Photographs which makes a strong case for developing RAW files, but with some twists. A little bit downstream of what you want to do.

But it could be you're creating a universal RAW processor for us - it would be good to wire it into a workflow so that any RAW can get passed through it, even if it's not scammed.

TBRC-Travis commented 7 months ago

Yes, I feel processing the RAW directly (and keeping them around) is the best approach.

We had a previous discussion about this which Jim captured here https://trello.com/c/lCN4KZmS/7-preservation-contents-raw-or-tif?search_id=04178f4c-c502-4571-8a8c-77292b317e7c

jimk-bdrc commented 7 months ago

Thanks - that was an interesting way to have cake and eat it too.

eroux commented 7 months ago

ok, just to document an interesting discovery: the digitizers in NLM1.0 had the original idea to shoot color cards with settings that are different from the rest of the images (ex in NLM1/W2KG208153/sources/W2KG208153-I2KG208393/MES_PO'I_ZHAL_LUNG_DUM_BO_DANG_DUM_BU_BZHI/, ME_PO'I_ZHAL_LUNG_0000.CR2 has an exposure of 4s and a color card, then ME_PO'I_ZHAL_LUNG_0001.CR2 has an exposure of 3s but no color card).

This means that we have to differentiate white balance compensation (that, I think, can still be based on the color cards) with exposure compensation.

Now, based on the background, compensating the exposure based on a linear interpretation of exposure time seems to do the trick (in this case multiplying all channels by 4/3), but I don't know how reliable it is. I'll implement two (optional) ways to do exposure compensation, one based on exposure time, one based on red channel average