ART (the software) news

[HIRAM (Richard E Barber)]

There was just one #include and a few packaging adjustments but it seems to build on Mac ok.

art.diff.txt (2.1 KB)

https://kd6kxr.keybase.pub/ART_OSX_10.14_64_0.2-13-gbf340d3cc.zip

[agriggio (Alberto)]

@HIRAM

There was just one #include and a few packaging adjustments but it seems to build on Mac ok

Thanks! updated

[gaaned92]

• sharpening

I noticed that the blurring of unsharpened regions was suppressed.
I think it is useful as you can mitigate the noise without fearing to destroy the sharpening.

Without this function, the sharpening can easily be defeated by the luminance denoising if you are not careful using the detail sliders. But it is tedious as you have to scrutinize the preview.

So I would like the luminance denoising could use the sharpening mask to denoise only unsharpened regions.

• local treatment

@srgmro

agriggio I think you succeeded in gathering the essential tools and bring to RT an efficient way to local treatment.

agreed,
but I am still wishing @agriggio implements a comprehensive (and of course simple to use ) mask generation tool

• https://keybase.pub/gaaned92/ART-W64NightlyBuilds/ART_master_0.2-14-g3de736d9e_W64_SSE4_191016.7z uploaded

[srgmro (Serge)]

@ff2000
I found an easy work around to the mouse scrolling. When it is becoming inefficient, I click once outside the ART windows and then once on the title bar of ART, and I recover the scrolling ability.
SM
Of course also efficient on RT

[srgmro (Serge)]

I would like to submit an observation on differences observed in lightness between the ART Raw preview and the preview of the Output JPEG file using the editor in the Multipe Tab Mode.
As an example I added the histogram of the Raw preview and of the JPEG file.
I do not observed such a difference with RT.
Where could it come from ?
My settings:
Working Profile : ProPhotoRGB)
Output Profile : RTv4_sRGB
I used a calibrate monitor Asus pro Art

First one Raw, second JPEG

The JPEG histogram exhibit less lightness than the raw one.

Thanks for your suggestions.
SM

[srgmro (Serge)]

To confirm, I collected in the pdf file RAW and JPEG histograms from both RT and ART.
It is clearly shown that the ART JPEG exhibit a shift towards left side of the histogram.
All data were obtained from the same raw file and the RAW process was the same.
I hope that could help.ART_vs_RT.pdf (94.7 KB)

[agriggio (Alberto)]

Hi,

@srgmro

I hope that could help

thanks for the info. If you are able to share the data (raw and sidecar files, both arp and pp3), I will take a look…

[srgmro (Serge)]

@agriggio

thanks for the info. If you are able to share the data (raw and sidecar files, both arp and pp3), I will take a look…

I upload a zip containing raw and jpeg data.ART_Data.zip (34.2 MB)

[agriggio (Alberto)]

Thanks. I had a look, at the “arp” has an output profile set to “RTv4_Wide”. That could explain the difference. If you set it to RTv4_sRGB, I see very little differences, to be honest. A couple more sources of discrepancies that come to mind:

• the dynamic range compression tool is not 100% accurate at zoom levels less than 1:1 (though this is usually minor)

• you are saving as jpg, which is a lossy format

[srgmro (Serge)]

@agriggio

Thanks. I had a look, at the “arp” has an output profile set to “RTv4_Wide”. That could explain the difference. If you set it to RTv4_sRGB, I see very little differences, to be honest. A couple more sources of discrepancies that come to mind:

I agree, I check all output profile and see no noticeable differences. How do you explain sensitive differences with RT, the shift of brightness is clearly visible. That is why when looking at jpeg file I detected the problem and that I carefully checked all my devices, and controlled with RT. It seems to me that histograms are a clear indication of some differences in the raw processing.
Thanks again for your interest.
SM

[agriggio (Alberto)]

@srgmro

It seems to me that histograms are a clear indication of some differences in the raw processing.

Well, yes, ART has definitely a different processing pipeline than RT. That’s one of the points of it Sorry if that was not clear…

[srgmro (Serge)]

As you suggested I checked for various format. In the upload file the Raw preview, the jpg preview and the tif one (32 bit float)

[srgmro (Serge)]

The updated french translationFrançais.txt (146.2 KB)

[agriggio (Alberto)]

thanks, pushed

[srgmro (Serge)]

When using color correction module, the default value for the pivot slider is 1. Won’t be better to settle it at 0.18 ?
Is there an easy way to do that ?
Thanks for your suggestions.
SM

[gaaned92]

perspective correction
The issue was not evident on the guggenheim museum photo.
It is more visible on simple geometric figure.

Original photo

RT vertical perspective correction

ART automatic vertical perspective correction

DT automatic vertical perspective correction

It can be noted that proportions in DT corrected image and RT corrected image are slighty different.
I can suppose that DT applies projection equations to original photo.
edit: it seems also that DT changes the canvas size from 900x596 to 999x602

[agriggio (Alberto)]

Seems more info is needed to reproduce…

[gaaned92]

I think I found the problem.
Starting from the jpg, the focal length is OK: 18 mm

When I process a raw without profile, initially the focal length in the tool is set to 105mm, which explains the problem.

raw uploaded at Filebin | mt7qykodgpadosxm

[agriggio (Alberto)]

@gaaned92

When I process a raw without profile, initially the focal length in the tool is set to 105mm, which explains the problem.

thanks! I’ll take a look

[agriggio (Alberto)]

@gaaned92

edit: it seems also that DT changes the canvas size from 900x596 to 999x602

yes, darktable changes the canvas size, and that’s the right thing to do. unfortunately this is not so easy with the current architecture of art, so I went for a compromise solution