Salut, @srgmro!
It works just fine here, using v0.3-43 on Manjaro/KDE.
Are you on Win, or Mac, or…?
Have fun!
Claes in Lund, Sweden
Salut, @srgmro!
It works just fine here, using v0.3-43 on Manjaro/KDE.
Are you on Win, or Mac, or…?
Have fun!
Claes in Lund, Sweden
Thanks, looking into it!
Linux Neon (ubuntu 18,04)
Sooooo… how come it does not work on 'buntu 18.04,
but it works on latest Manjaro/KDE?
the crash was happening on export, did you try that? anyway, It should be fixed now
training on local editing
I was doing some training on the photo from [Play Raw] cumulus beach
I made this correction DSC_4165.nef.arp (24.7 KB)
And I observe what I think is a bug.
Can you confirm it is a bug? Then I will open a ticket.
Yes it occurs at export and it is fixed.
Thanks a lot Alberto
confirmed. I should have fixed it about one hour ago… can you please test?
Thank you. Working ok
ART-W64NightlyBuilds/ART_master_0.3-45-g9f62dad3c_W64_SSE4_191225.7z uploaded at
https://keybase.pub/gaaned92/ART-W64NightlyBuilds
@agriggio @sguyader A new french translation file. It concerns line 2003 and 2006. Slightly shorten check button text to allow a normal shrinking of the right panel.
I updated this post to take into account the new lines 813, 1970, 1971 and 1975 for Log encoding optimisationFrancais.txt (150.7 KB)
I stumbled upon this problem
I tried to use the same minimum processing in RT and ART
I notice the following facts:
the two log-log histograms are very different. In the ART photos there are clipped highlights and shadows in contrast with RT image. I don’t know what is correct.
in ART I am unable to get back the shadows and highlights without destrying the image.
I am surely missing something. Thank you for help.
Hi,
Well, the pipelines are different, so this is not surprising.
The ART histogram will show a colored rectangle at the border of the histogram if there are any clipped pixels in the image. In RT, the logic for showing the rectangles is different, and I actually cannot quite understand it, sorry.
I don’t know what is correct.
You can use the inspector in “raw clipped pixels” mode to confirm that there are clipped pixels in the raw file:
I’m not sure I understand what you mean here. Can you be more specific? If you you mean that you want to get rid of the clipping indicators in the histogram, then it’s not surprising that it requires a lot of work and the result is not nice, since those pixels are clipped already in the raw.
Hope this helps!
Yes, definitely. In rawproc, I just set the whitepoint at the minimum of the channel maximums and pray a contrition to @aurelienpierre…
I’ve now compiled both RT and dt current, and in the new year will mess with the respective reconstruction capabilities, particularly RT so I can understand how to use the librtprocess recovery function. Thing is, some scenes are just challenging this way, and for most cameras putting those highlights in definition will make dealing with the shadows even more challenging, no matter the software.
Looking forward to our visit to the same cabin next year, so I can set up an equivalent scene, expose it ETTR, and see how the shadows fare from the Z6 sensor…
@agriggio I updated the french translation file, which include all the improvements you bring recently (new lines 821, 1983, 1984)Francais.txt (150.8 KB)
I do see the raw clipped highlights. but for clipped shadow I can hardly see them. I only see some colored pixels in the shadow zone.
clipped shadows indication zone : when I hover on the clipped shadows zone, the RGB values seem always greater than 0. I imagine there are only a few clipped pixels in the zone.
I tried in ART to get the same non clipped histogram as in RT. That was indeed a complete failure.
hi,
those are your clipped (clamped) pixels. the colour indicates which channel is below the black level
ART and RT apply camera input profiles in a (slightly) different way, so that might be it. I’ll take a closer look when I have the chance
Just curious is there an explanation of how the pipeline for ART differs from RT and why the changes were made? (Just a brief overview if it’s not to complicated to explain?)
It is indeed a bit complicated to explain. There are different reasons:
to have a clear separation between tools operating in “scene referred” space and tools operating in “display referred” space, similarly to what is happening e.g. with darktable
to have a more modular organisation of the code
to fix (what I perceived to be) some inconsistencies in the way some tools were applied
finally, it is likely that some changes were purely accidental
Just to be clear, though, I think there’s nothing wrong in the way things are done in RT. I just had a different opinion about some things and wanted to try some alternatives. Not being constrained by backwards compatibility (which is very important for RT) made experimenting quite easy.
That sounds good, thanks for the explanation.