Download RawTherapee development builds

This post has been made obsolete.

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

14 Likes
Local Lab build
NEF wrong colors and low contrast
Re: Download RawTherapee builds (Windows, macOS, Linux, AppImage, other)
Local Lab build
Local Lab build
Red eyes removal?
Compile under Windows
Red eyes removal tool?
[Play Raw] Processing a very high-contrast raw
Dev build supporting compressed Fuji raf files
GIMP 2.10 and RT on Win7 ?
RT is running slow on my new iMac
A new dev branch build for macOS
Raw Therapee 5.5 on Mac OS 10.11.6: crash on launch
batch queue crash
download-rawtherapee-development-builds/2924 unpinned
RawTherapee 5.3 Released
Branch: newlocallab with GUI pull #4836
Sony pixel shift support for Mac version of Raw Therapee?
problem running RT in OSX 10.11.6
Win 32 Build Please?
(Windows) The mouse doesn't seem to know where it is
RawTherapee 5.2 macOS 10.9+ build available
Testing RawTherapee on macOS X 10.9 Mavericks
Processing Queue
RT is running slow on my new iMac
RawTheapee and Nikon COOLPIX B700
how to get for linux 64bit
RT: troubleshooting
Community-built software
Ricoh GRD II and Auto-matched tone curve problem.
Raw and DNG files do not look the same
Raw and DNG files do not look the same
Trying to emulate Adobe's clarity in RawTherapee
Help test RawTherapee on Retina/4k etc HiDPI monitors.
Profiled Lens Correction is missing my camera/lens
Some problems with RT 5.3 and 5.4
Some problems with RT 5.3 and 5.4
Local Lab build
Now is the time
Rawtherapee Retinex and Non-raw files
Bug : RT quits unexpectedly when reading directory with RAF+PP3
Help with a RAW file
TIFF and PNG files
Help test RawTherapee on Retina/4k etc HiDPI monitors.
[Playraw] Presolana (was: Salvaging a raw)
RT is running slow on my new iMac
Quick question on RT Richardson–Lucy implementation
Latest RTW64NightlyBuilds not working for me
Does soft-proofing work without looking to the output profile?
Raw Therapee is Fuji XT-3 functional - almost
Raw files pink when open
Help for newbie: Win 10 - RT has stopped working. A problem caused
Access to "Download Rawtherapee builds" post
Empty File Browser
Slow launch and image loading (5.0-r1 GTK2/GTK3 on Win10)

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,

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?

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 .

@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…

Yes and no!

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

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

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

1 Like
  • 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?

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.

@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

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

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?

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

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.