Download RawTherapee development builds

Software RawTherapee
1

This post has been made obsolete.

To download bleeding-edge development builds, see the Download article in RawPedia.

14 Likes
26

Hi,

With all due respect, but not entirely obsolete, I suppose.

The old “Download RawTherapee development builds” pinned topic also provided links to the AndrĂ© Gauthier vel “gaaned92” various RawTherapee compilations.

There is currently no easy way to find these links, I suppose.

The link provided in RawPedia only leads to automatic builds on GitHub.

If, of course, André does not mind, maybe it would be possible to put a link to his compilations somewhere on the forum or possibly made a topic also for other people who have knowledge and capabilities do it.

Regards,

27

The automated build toolchain is transparent and consistent, and is also used for stable releases, and so it should be used for testing.

What is your reason for wanting @gaaned92’s builds?

28

I don’t know about windows builds, but maybe it’s interesting keeping those and the appimages links, just to have them in a well known place .

29

@Morgan_Hardwood @gaaned92 @heckflosse
I have been thinking about the naming of the development builds I am providing.
The current scheme is the following:

  • linux appimages:
    RawTherapee-${RT_BRANCH}-${GIT_DESCRIBE}-${DATE}.AppImage
  • Win64 packages:
    RawTherapee_${RT_BRANCH}-win64-${GIT_DESCRIBE}.zip
    or
    RawTherapee_${RT_BRANCH}-win64-${GIT_DESCRIBE}_WinVista_64.exe

While this allows to determine the git commit from the package name, it generates packages with names that change every time.

This might be a problem if you want to provide links to the most recent development builds. Moreover, the git commit information is also available in the AboutThisBuild.txt file.

So I would propose the following alternative scheme:

  • linux appimages:
    RawTherapee_${RT_BRANCH}_linux.AppImage
    and a copy of AboutThisBuild.txt as
    RawTherapee_${RT_BRANCH}_linux.txt
  • Win64 packages:
    RawTherapee_${RT_BRANCH}_WinVista_64.exe
    RawTherapee_${RT_BRANCH}_WinVista_64_portable.zip
    and a copy of AboutThisBuild.txt as
    RawTherapee_${RT_BRANCH}_WinVista_64.txt

What do you think?

Another consideration: currently the packages are built with very generic processor flags (-DPROC_TARGET_NUMBER="0" for the AppImage, -DPROC_TARGET_NUMBER="1" for the Windows builds). However it would be rather easy to create additional builds for more specific target processors, in order to take advantage of specific optimizations. This would mostly boil down to adding another environment variable in the Travis build matrix, and then updating the build script to adjust the processor target according to the specified environment.

Would this be useful? Any suggestion for specific processor targets? I think that one or two specific targets would be a reasonable compromise


30

Yes and no!

No, use features (e.g. -msse4 or so) instead of targets

31

Fine as well. Then we should agree on the list of features to be enabled


32

Imho a default build without additional features being enabled, a build with -msse4 and a build with -mavx would be fine

1 Like
33

  • naming of builds
    I agree with de suppression of commit identification that can be found in the AboutThisBuild.txt.
    I was also asked to provide a date in the build name to identify if it is recent or old.
    If you build for different architectures, I think you will have to include an architecture identification in the name

  • different architecture
    I know the position of @heckflosse. I still don’t understand why building for a modern architecture would not be beneficial compared to -mtune=generic -msse4 -mavx.
    But he is the performance wizzard :grinning:

@heckflosse I remember that you made some posts about multiversionning (perhaps FMV?). What dou you think of that?

34

Building for the exact architecture you use will always be beneficial if the machine you run the program does use the same architecture.

But for example a -march=bdver1 build might or might non run at all on a Intel cpu and vice versa. And even if it runs, it might not run optimal, maybe even worse, as the compiler also takes into account things like L1 cache-size of the target you compile for and which the preferred SIMD size of the target is and so on.

35

@gaaned92 Also, it’s not only about performance. Assume you make a build for a target which supports AVX and also, though you didn’t notice that: F16C.
Now a user downloads that build because his machine supports AVX. If his machine does not support F16C (though I don’t know if there are cpus which support AVX but not F16C) he will get a crash as soon as he opens a 16-bit-float DNG from hdrmerge.

1 Like
36

That is not a problem. Development builds are for testing by experienced users, who may want to download and concurrently run several different builds. Not having the necessary info in the filename means you’d end up with:

RawTherapee_${RT_BRANCH}-win64.zip
RawTherapee_${RT_BRANCH}-win64-1.zip
RawTherapee_${RT_BRANCH}-win64-2.zip
etc.

That would be a regression.

It’s more useful in the filename.

And speaking of AboutThisBuild.txt, it was necessary to package this text file inside the ZIP for historical reasons. We no longer need that. It’s still a good idea to include AboutThisBuild.txt in the build, but it can now be left within the installer/appimage/dmg, it no longer needs to be outside of it.

Having “Vista” in the filename was needed when we still provided WinXP builds. That is no longer the case, so we can drop “vista” (it sounds bad).

So I would propose:

  • RawTherapee_lin_${RT_BRANCH}-${GIT_DESCRIBE}-${DATE}.AppImage
  • RawTherapee_win_${RT_BRANCH}-${GIT_DESCRIBE}-${DATE}.zip (containing the installer)
  • RawTherapee_mac_${RT_BRANCH}-${GIT_DESCRIBE}-${DATE}.zip (containing the DMG)

I don’t know whether 1 is still the best value, being 2019 and considering we don’t ship 32-bit builds. I agree with @gaaned92 that we should build for a more modern arch if possible. Maybe @heckflosse can suggest better optimizations safe for 64-bit CPUs capable of running Vista and upwards.

I don’t want to go down that rabbit hole. User goes to our website, hits a wall of confusion, “Which one do I want?”, downloads one, and it crashes. It’s not something users would understand, it’s not something other programs do, and it would cost 3x the bandwidth. Let’s decide on one build with better features.

Those extremely few users who need every last bit of performance can always compile a native build for their CPUs themselves. Since those users happen to be companies and can afford consultation, compilation is not a problem.

1 Like
37

Ok, let’s go for this. What about the portable Windows version, the one without an installer? Should I simply drop it or the future, or is there an interest for it?

38

Stable releases need the installer, while development builds would be more handy without one.

39

I just installed one yesterday (with the installer) on an external drive. Worked perfectly. I have the current 5.7 final on the main SSD.

40

Morgan, can you tell me where ‘Camera Calibration’ heading is please on Raw Therapee