ART Project Changelog
In reverse chronological order, this pages describes the releases made on the master branch of the ART
git repository. The version numbering follows a standard logic:
- Bugfixes yield minor version bumps in the third component (x.y.z)
- Significant additions of functionality generate an increase in the second component (x.y.z).
- Only major structural alterations cause the first component to be increased (x.y.z)
In the initial phase after release, the major/minor rule will actually be occasionally broken: bringing back various pieces of unstable functionality which were dropped in the run-up to public release will only generate a minor version bump.
Please also note that the project version number is only bumped iff changes are made to the actual source tree. Changes to the gallery scenes and/or the documentation do not generate a version bump, but are also noted on this page.
December 17th, 2018
ART can now output colourspace
The default type of
artrawwhich is output by ART can now be controlled via an environment variable called
- 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.
- As they should have been all along,
exrimages are now being sent through the same white balance pipeline as
exrimages 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.
If you came across the definition of
ArSpectrumTypewhile 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
Foundationpart 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.
ArRGBis 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.
October 17th, 2018
- White balance tools for colour correction of spectral output images are now provided.
- The Oren-Nayar BRDF model is back.
- 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.
- 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.
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.