ART 1.4: Path to HaldCLUT in Windows & Linux different - selected film simlations are not found / applied

[Mike]

I am currently testing the latest 1.4er version on Windows 10 Pro and a virtual Linux Mint 19.3 for general use and especially for inter-operability between both OS. The intention is that I like to use ART on a MS Surface Pro and transfer/syncing the resulting file one way to my desktop (because I like to replace the Windows OS with Linux after finishing my PhD with MS Word). Thus, the used tools within ART should be compatible on both platforms to prevent validating and processing RAW twice.

All my test I do with separate folders of the same test files of my cameras and potential other RAW files. The *.arp files were written first on the Windows platform and transferred to Linux. Also the HaldCLUT files were copied locally to an identical location on Linux.

Now to the observed issue:
On the Win-ART version I created snapshots and applied a film simulation, copied the processing file to Linux and reopened ART there. I also cleared the cache, just to be sure. Unfortunately, the previews for the processed RAW file do not show the previously applied film simulation.
Checking the selected film profile in the film simulation module shows an empty field, but when clicking on the drop-down one has access to the installed LUT files.
So, I selected a LUT in Lin-ART and compared the arp-files of both OS versions
→ both use a relative path to the LUT → good
-> nevertheless, the delimiter are different → Linux could not find the LUT defined in Win-ART, e.g.:

• Win-ART:ClutFilename=Black-and-White\Agfa\Agfa APX 25.png
• Lin-ART: ClutFilename=Black-and-White/Kodak/Kodak T-Max 100.png

So, I guess a standard for path descriptions need to implemented and then interpreted on one or the other OS version of ART.

Cheers

Mike

[Gaaned92]

W10, built done with MSYS2

I checked what is written in the ARP file. I get this fancy file path:

ClutFilename=file://R/Color/Kodak/Kodak%20Kodachrome%2064.png

It seems to work if file://R/ is suppressed but is written back when the ARP file is saved.

So file path encoding could depend on the build environment

[agriggio]

sorry, I don’t understand whether it works or not… what is written is what is expected, but does it work? What does this:

It seems to work if file://R/ is suppressed

mean exactly? Here’s a test you can perform:

• open a raw file, apply neutral
• select a film simulation
• quit art, so the arp gets saved
• reopen art and reload the raw

If the film simulation is applied correctly, then “it works”. Otherwise, “it does not work”. Which of the two?

Thanks!

‌

[Gaaned92]

It works

What intrigates me is that on Windows I get linux file path with slashes and “file://R/” prepend that is:

ClutFilename=file://R/Color/Kodak/Kodak%20Kodachrome%2064.png

instead of

ClutFilename=Color\Kodak\Kodak Kodachrome 64.png

as it is written by rawtherapee and observed by Michael Hamer

sorry for the noise.

‌

‌

‌

‌

‌

‌

[agriggio]

What intrigates me is that on Windows I get linux file path with slashes and “file://R/” prepend that is:

well, but that’s exactly the point here: to have arp files that are independent of the platform in which they were generated, so you can reuse them across systems. There are still other things to do, but this is a first step towards that.

Thanks for confirming!

[Mike]

Hi,
I had a minute to test the issue on a virtual MacOS Mojave to get a more complete picture:
Beside the reported issues of this “experimental” version in the discussion at https://discuss.pixls.us/t/multiples-issue-on-mac-os-high-sierra/18532 I could define a path for the LUT, identical to the previous OS. ART start but does not see earlier applied film simulations. On a blank file I can select a simulation but, unfortunately, at about 30% ART freezes when applying (I guess) the LUT. Nevertheless, ART writes the selected LUT into the arp-file and it is identical to the version on my Mint Linux:

• MacMojave-ART: ClutFilename=Black-and-White/Agfa/Agfa APX 25.png

By the way, maybe it might be a good idea only to write “enabled” settings into the arp-files to reduce redundancy. Especially, when making use of several snapshots the arp-files getting quite large. I don’t know the ART / RawTherapee strategy for this, and it’s possibly due to compatibility or other routines?

[agriggio]

Hi, would you be able to test the latest version?

maybe it might be a good idea only to write “enabled” settings into the arp-files to reduce redundancy

not going to happen, sorry. There are valid reasons to have arp files with non-default settings but still disabled.

[Mike]

Hi,

I did some quick test during my coffee break on all the mentioned OS.
For this testing I used the following binary images:

• ART_master_1.4-7-g25623545e_20200612_win64.zip
• ART_master_1.4-7-g2562354_20200612_macos.zip
• ART_master_1.4-7-g2562354_20200611_f2e74a6441199936d126127daebfc8ad.AppImage

There are good news!
Firstly, on all 3 platforms the path for the film simulation looks identical and reads like this example:

• ClutFilename=file://R/Color/Kodak/Kodak%20Kodachrome%2064.png

Secondly, the exchange of settings works fine back-and-forth on Windows 10 Pro and Linux Mint 19.3. Due due the crashes on MacOS I couldn’t confirm if it is working there also.

‌

During this test I found on all OS that the 1-star rating is not shown as filled. Only an empty star is shown, even when the image is rated higher … I will put it into new issue.