ART Project Changelog

The releases made on the master branch of the ART gitlab repository, in reverse chronological order.

2.1.1

February 2022

Project management

• ART is now a project on gitlab, and all development coordination is done via there.

New features

• Our new sky model is supported, although with a rather inefficient proof-of-concept C implementation. As part of the Intel OneAPI effort, a more efficient C++ library to access the model is coming soon. This will be integrated into ART in a future release: for now, scenes that use the new model are very slow.

• ART fully supports the spectral OpenEXR extension that was recently proposed. Spectral OpenEXRs can be used instead of ARTRAW images.

• There is now an ArCIELch colour data type, which is a polar coordinate counterpart to ArCIELab.

• There is now a “manual” gamut mapping mode, which is still somewhat experimental. Best results are still achieved by using the littlecms routines, which remain default.

Bug fixes

• ART now builds again on all recent versions of Linux and MacOS - in particular, on Apple silicon machines, with their code signing requirements.

• Lots of smaller bugfixes as well, in particular in conjunction with fluorescence rendering.

2.0.3

March 4th, 2019

New features

• We now support colourspace image maps, a.k.a. textures. In this initial release, any colour space information found in the header of input images is ignored, and the spectral uplift is hard-wired to assume all inputs are in sRGB space.

• As part of the texture support, spectral uplifting according to the technique recently introduced by Wenzel Jakob and Jo Hanika has been added to ART. Note that the tool used to generate the .ucc sigmoid coefficient file for sRGB which is distributed with ART 2.0.3 is not included in the codebase: for various reasons, this tool will remain closed source.

• ArHSV data type added, to provide RGB values via the familiar “hue-saturation-value” logic.

• tonemap now has an additional tone reproduction operator called -stu, which stands for scale to unity. It is a very simple operator which simply scales an input image so that the maximum luminance in it is mapped to one. This is useful when turning .exr files into reflective textures.

• The -acesRGB option has been removed, and replaced by -ap0 and -ap1. This now allows users to choose either of the ACES RGB spaces, as they should have been able to do all along (the old option only offered AP0).

New resources

• A texture demonstration scene (CornellBoxImageMap.arm) has been added to the Gallery.

Bug fixes

• A mistake in how lockless assembly instructions were used has been corrected in the case of m_ii_add(). Chances are that the incorrect usage could have led to unpredictable behaviour while multi-threading. The remaining lockless functions will be fixed in the next release.

Code cleanups

• Thomas Gamper has started an effort to find memory leaks and unsafe code sequences throughout ART, and a number of fixes for problems he found are included in this release.

2.0.2

December 17th, 2018

New features

• ART can now output colourspace artraw images again.

• The default type of artraw which is output by ART can now be controlled via an environment variable called ART_DEFAULT_ISR.

New resources

• Three scenes which demonstrate polarisation features have been added to the gallery.

Changes in default behaviour

• ART now again uses the CIE 1932 2 degree standard observer functions, instead of the CIE 2006 2 degree candidate functions which were used in 2.0.0 and 2.0.1. In the future, selection of the colour matching functions will become properly switchable: but for the meantime, reverting to the widely used 1932 curves makes more sense than going with the still rarely used 2006 versions.

Bug fixes

• As they should have been all along, exr images are now being sent through the same white balance pipeline as tiff images. Also, exr images now use the RGB primaries of the selected RGB space, instead of silently defaulting to sRGB. And unlike tiff (which, as it should, uses whatever gamma is appropriate for the selected RGB colour space), they are in linear RGB.

Code cleanups

• If you came across the definition of ArSpectrumType while browsing the ART codebase before this update: please forget what you saw, and we apologise if you wasted time trying to actually understand what was there. The enum in question still exists, but has now been re-named to ArDataType. The new definition gets rid of 20+ years worth of organic growth, and only contains stuff that is actually relevant to ART in its current form. This cleanup also had a number of small knock-on effects throughout the codebase, so quite a number of files have minor edits.

• The low-level colour data types in the Foundation part of ART were considerably cleaned up and simplified. The system of attaching colour space tags to tristimulus values was completely dropped, as it was unnecessarily complex, and not used for anything meaningful. ArRGB is now just a simple triplet of doubles, as it should have been all along. And it is the responsibility of the user to make sense of the colour space an RGB value is supposed to be in.

• Creation of chromatic adaptation matrices is handled a lot more sensibly than before.

2.0.1

October 17th, 2018

New features

• White balance tools for colour correction of spectral output images are now provided.
• The Oren-Nayar BRDF model is back.

New resources

• The test scene from our 2018 EGSR paper is now included in the gallery.
• There are now colour chart images for the entire Munsell Book of Color.

Bug fixes

• Hero sampling of environment light sources now works properly.
  This bug caused the colour chart example scenes, which are illuminated by a uniform environment, to have a colour cast if the light source was a spiky spectrum, such as one of the CIE fluorescent luminaries.

2.0.0

September 26th, 2018

Initial release version notes.

Let’s be frank here: if it was not for the fact that we really, really wanted to release ART on or before September 26th, 2018, the code you see now would have stayed in beta. And here we are talking about issues that go beyond the already daunting list in the state of ART on release day.

The documentation has not been completely proofread and has typos etc. aplenty, there are only a few example scenes in the gallery, and the path tracer is still somewhat dodgy. Not because it is a bad path tracer per se, but because it has simply not been tested that to the point where we would be confident it doesn’t do stupid things when you feed it arbitrary scenes. In our defence, the current MIS path tracer is still pretty new: it was recently re-written from scratch to modern standards by Michal Mojzík, and replaced an ageing monstrosity that had clearly run out of maintenance options. Michal did a great job, but non-trivial path tracers are complex beasts: so it will probably be a while before all fleas have been combed from its fur.

Somewhat embarrassingly, one of the areas where there are still rough edges is actually the Hero sampling functionality of the path tracer. In particular, you cannot use SMOOTH_FRESNEL_SURFACE as the top layer in a LAYERED_SURFACE, and all SMOOTH_FRESNEL_SURFACE degenerate into monochrome tracing regardless of whether the underlying material exhibits dispersion. This will be easy to fix, but not before release.

Regarding Hero sampling, if you have doubts for any given scene, try running artist in monochrome mode via the -m command line flag: given enough samples, the two images eventually have to match, otherwise something is wrong.

On the plus side, we do have a large number of example scenes still lying around: these will be re-added to the source tree over the next weeks, along with a few modules which were dropped at the last minute due to minor defects. So you can realistically expect a number of point updates from mid October onwards. Until then, the two team members who were working on the release are moving, as both of us will not be spending the winter semester in Prague.