The new "Snapshots" system in Spectral Workbench brings the ability to maintain different versions of a spectrum for different uses. This feature [has been largely implemented in Github](https://github.com/publiclab/spectral-workbench/issues/192) and will be coming online in January 2016. ##What are Snapshots? Snapshots freeze a specific state of your spectrum so that the data as it exists at that moment can be used in other contexts, for example by other users. It's like **version control for your data** -- if you use a spectrum by reference, such as to calibrate, or in a comparison, you can expect that you'll see the snapshot of that spectrum just as it was when you made that reference (see [References vs. Snapshots](#References+vs.+Snapshots) below). No later changes to the spectrum will affect referring work. Snapshots are listed with a small "thumbtack" icon next to the operation that generated them (see below). They look like this, and you can hover over them for more info: [![Screenshot_2016-01-11_at_5.24.33_PM.png](//i.publiclab.org/system/images/photos/000/013/616/medium/Screenshot_2016-01-11_at_5.24.33_PM.png)](//i.publiclab.org/system/images/photos/000/013/616/original/Screenshot_2016-01-11_at_5.24.33_PM.png) **** ##When are they created? Most [Operations](/wiki/spectral-workbench-operations) applied to spectra cause snapshots to be created automatically, so that a "frozen" version of the spectrum is permanently available for that operation's use. These include the `calibrate:`, `subtract:`, `transform:`, `range:`, `crossSection:`, `smooth:`, and `flip` operations. A full, current list of tags that generate snapshots is [in the `tag.rb` model file](https://github.com/publiclab/spectral-workbench/blob/master/app/models/tag.rb). ##Who can create them? Since only the owner of a spectrum (or an admin) can add operations, the same is therefore true of their corresponding snapshots. ##References vs. Snapshots We refer to snapshots in two contexts, which should not be confused. Basic snapshots are those generated by an operation. **References** are the snapshots which operations _refer_ to, and appear in the operation name after a hash mark - `#`. This will typically look like: subtract:24#151 Here, the `subtract:` operation will have generated a snapshot, but it also contains a **reference** to another spectrum, and a specific snapshot of that spectrum -- the snapshot with id #151. Note that creating this `subtract:` operation will lock that reference snapshot #151, so it cannot be deleted or modified. That's the point of snapshots! [![Screenshot_2016-01-07_at_2.49.30_PM.png](//i.publiclab.org/system/images/photos/000/013/540/medium/Screenshot_2016-01-07_at_2.49.30_PM.png)](//i.publiclab.org/system/images/photos/000/013/540/original/Screenshot_2016-01-07_at_2.49.30_PM.png) ##Locking and forking You'll see a "padlock" symbol next to some snapshots, preventing you from deleting them. Basic locking is just ensuring that if you delete snapshots, you do it in reverse chronological order. These lock icons will appear dark grey. The other kind of locking displays a blue padlock icon. As mentioned just above, **referencing a snapshot will lock it** -- and any registered user can reference a snapshot. The idea is that once someone -- you or anyone else -- begins to rely on a given spectrum, that version of the spectrum (as captured in the snapshot) should be permanent and uneditable. You can rest easy that nobody can change a snapshot that you've relied upon in your own work. If you or someone else has caused one of your snapshots to be locked, but you really must do something different with that spectrum, you can **fork** the spectrum. This makes a copy of the spectrum, all its tags, and all its operations, none of which will then have a lock. You can then delete the operations and do what you like with the spectrum. **** ##Why are they necessary? Snapshots ensure that if you rely on a spectrum for any of the operations above, any subsequent changes to that spectrum do not (by default) affect your reference to that spectrum. Your reference is to the snapshot, not the spectrum, and nobody can modify that data unless all references to that snapshot are deleted. So if you use one spectrum over and over, for example as a calibration reference, or as a baseline to subtract with, you'll always be accessing the same data. If you change the referred-to spectrum later, you'll be able to manually [update](http://driverrestore.com) the reference to a more up-to-date snapshot. But this won't happen automatically. ##Changing reference snapshots You can update the reference in an operation only if that operation's snapshot is not itself referenced (if it is, you'll see a blue lock icon and won't be able to delete it). That way, you can re-assign the referenced snapshot, but not if it'll affect any referencing operations. In terms of permissions, this works similarly to deleting snapshots. The menu looks like this: [![Screenshot_2016-01-07_at_2.56.38_PM.png](//i.publiclab.org/system/images/photos/000/013/541/medium/Screenshot_2016-01-07_at_2.56.38_PM.png)](//i.publiclab.org/system/images/photos/000/013/541/original/Screenshot_2016-01-07_at_2.56.38_PM.png) ##Contributing The framework is designed to be flexible and extensible, as we add more abilities to Spectral Workbench. Please contact the [developers list](/wiki/developers) with ideas and suggestions for new features and future versions, and check out Spectral Workbench on Github at https://github.com/publiclab/spectral-workbench. Also check out our [Contributing to Public Lab Software page](/wiki/contributing-to-public-lab-software).