Some PhF Layout suggestions

I’v checked apps from AUR, not appImages.

appImage works OK

1 Like

Great!

Where is color adjustment in a new version of PhF?

It is in the color group:

Is that what you are looking for?

I’m stupefied but PhF can’t open RAW from Fuji X-T4 :face_vomiting: Art and rawtherapee opens this raw without problems.

New camera new code required? Do share file for testing before complaining.

2 Likes

PhF is based on DT/RawSpeed. I just tried to update the code to the current DT/RawSpeed git head but the X-T4 is still not recognized. I am afraid we need to wait until proper support is added to DT.

RT/ART use a completely different RAW loading code.

Meanwhile the X-T4 doesn’t even ship until April 30th.

1 Like

Hi!
I’m working with the last version of appimage and with the last version of AUR. Both have strange effect in Sharpen.DL Reconstruction plagin.

Artifacts removed with plugin only.

Hi! I cannot reproduce the problem. Could you maybe share the input image and the .pfi file?

Thanks!

Here is sample image from X100S and .pfi

samle.zip (24.8 MB)

I found the reason for the artefacts: they are due to negative RGB values that are introduced by the contrast adjustment. I will implement a proper fix. Meanwhile, you can avoid the image corruption by inserting a “Color/clip values” layer just below the sharpening layer…

As I remember, here I increase exposure (about 1.6 times) and set white point by color pointer. From where negative RGB?

For such type of image, I would strongly suggest you to give the “Enhanced USM” sharpening a try… here is my result:

no sharpening:

RL deconvolution:

Enhanced USM:

Those are the settings I have used:
Screen Shot 2020-04-12 at 3.36.06 PM

From the contrast adjustment in the “basic adjustments” tool:

Screen Shot 2020-04-12 at 3.39.52 PM

Hm…
About sharpening - local contrast about 70% gives a sharp view :smile:

By the way - can I work with back level now?

Do you mean in the RAW decoder? Yes, it should work properly now, at least for non-Nikon cameras (Nikon cameras subtract the black level already when saving the raw data, and my current code does not deal with that properly).

FWIW, I just inspected the metadata from a D7000 and a Z6, where the the latter requires a black subtract and the former does not, and the distinction can be made in the presence of the MakerNotes:BlackLevel tag.

Actually, to properly handle black subtraction across all cameras, three cases need to be handled: 1) a single black level, subtracted from all three channels; 2) per-channel black levels, and 3) a black level array corresponding to the CFA pattern. Funny though, every raw file I’ve encountered with either #2 or #3 has had the same value in all the positions… :smiley: