Photoshop calls it Snapshot.
It saves your current state of edits and you easily get back to that point.
Useful addition to the undo list.
Snapshot in Undo List
-
- Mitglied
- Posts: 2370
- Joined: Sat 12 May 2012 21:38
Re: Snapshot in Undo List
It would indeed be nice if PhotoLine would support some kind of built-in version tracking. Photoshop's history snapshot sort-of solves this, but since it relies on working within Photoshop this is not a great approach when working with various design files within a larger project and/or when working with a team. A more managed approach is required.
And that requires a proper version control system (VCS) such as Git or SVN.
It means we can track the history (create "snapshots") of our PhotoLine project files and other design files (Blender 3D files, etc.) using either Git or SVN.
(warning: this is a bit theoretical and if you've never worked with --or even never heard of-- version control systems before it may read like technical gibberish
)
A version control system allows us to track the history of all files in a project. But also to create tests and different versions (branches) of the states of that project.
Nowadays most developers tend to favour Git.
For my professional and personal work I also use Git for version tracking. That works well for atomized file based projects like game projects or app development projects. (Atomized meaning: the main project is built out of and organized using many smaller files "atoms")
I use mostly Godot for game dev, and those projects are mostly made up of many small text files that describe how the content of the game works together. Git works really well with text-based files, and only tracks (stores) the changes in those files. (Not the entire text-based file, which saves a lot of storage!)
But version tracking design projects with binary large objects (BLOBs) such as PhotoLine files or animation projects, etc. is problematic in Git, since for each revision it will save a complete copy of the change file(s), rather than the differences. That means that if we have a 500mb large PhotoLine file, EACH version will take up that SAME amount! Tracking 2 versions of the original file will mean a 1.5GB large tracking history!!!
This is not sustainable: imagine having 50 versions... 50 * 500mb = 250GB to track!
That's why I use SVN instead of Git to keep track of pure design projects. (And SVN is also much easier to understand compared to the workflow in Git for most users). The main difference between Git and SVN in regard to binary files is that SVN will track the actual changes only and save those.
For example, moving a layer and adding an adjustment layer or two for a typical PhotoLine PLD file of 500mb will only mean a ~1mb file change in SVN. Which means SVN tracks minor and large changes in a huge design file very easily.
BUT ONLY...
...WHEN and IF compression of those binary files is turned off. Compression of native binary source files generally changes the entire binary file, or large swathes of it. Which means SVN will store MUCH larger differences. So ideally the design app allows us to TURN OFF compression for its binary design files.
As it turns out PhotoLine allows us to do just that:
By turning off compression and activating quick saving SVN will track the differences to a BLOBs (binary large objects) only.
Animation software like OpenToonz / Tahoma2D also makes use of SVN for these reasons. The advantage of OpenToonz (or Tahoma2D) is that it already supports SVN directly in the application, which means a simpler and smoother workflow experience for the user (animator).
Blender (3d animation software) also works well with SVN and there is an addon that takes care of (hides) the SVN integration.
*** end of version tracking explanation ***
So how does this actually work in practice? Let's assume we want to work with either a new or existing PhotoLine file and keep track of versions (the history --> create history snapshots).
I assume we are working on Windows here. TortoiseSVN is not available for Macs, unfortunately. SmartSVN or SnailSVN are (paid) alternatives for Mac users. I have not used these myself.
It would be awesome if PhotoLine would get its own built-in SVN tracking panel, but honestly this falls WAAAY out of the scope of most users' workflow and/or experience here. I am pretty sure 99.9% of PhotoLine users would never make use of it
...which brings us back to your request of a simple history snapshot feature in PhotoLine
For many PhotoLine users a simple history snapshot function would be quite helpful.
Anyway, SVN allow us to take control of version tracking of design projects. It's actually pretty easy to understand and use once you start using it, and I would heartily recommend this to anyone wanting to track versions / history of a larger design project that one is planning to work on. It has saved my butt (and others I work with) many times.
And that requires a proper version control system (VCS) such as Git or SVN.
It means we can track the history (create "snapshots") of our PhotoLine project files and other design files (Blender 3D files, etc.) using either Git or SVN.
(warning: this is a bit theoretical and if you've never worked with --or even never heard of-- version control systems before it may read like technical gibberish

A version control system allows us to track the history of all files in a project. But also to create tests and different versions (branches) of the states of that project.
Nowadays most developers tend to favour Git.
For my professional and personal work I also use Git for version tracking. That works well for atomized file based projects like game projects or app development projects. (Atomized meaning: the main project is built out of and organized using many smaller files "atoms")
I use mostly Godot for game dev, and those projects are mostly made up of many small text files that describe how the content of the game works together. Git works really well with text-based files, and only tracks (stores) the changes in those files. (Not the entire text-based file, which saves a lot of storage!)
But version tracking design projects with binary large objects (BLOBs) such as PhotoLine files or animation projects, etc. is problematic in Git, since for each revision it will save a complete copy of the change file(s), rather than the differences. That means that if we have a 500mb large PhotoLine file, EACH version will take up that SAME amount! Tracking 2 versions of the original file will mean a 1.5GB large tracking history!!!
This is not sustainable: imagine having 50 versions... 50 * 500mb = 250GB to track!
That's why I use SVN instead of Git to keep track of pure design projects. (And SVN is also much easier to understand compared to the workflow in Git for most users). The main difference between Git and SVN in regard to binary files is that SVN will track the actual changes only and save those.
For example, moving a layer and adding an adjustment layer or two for a typical PhotoLine PLD file of 500mb will only mean a ~1mb file change in SVN. Which means SVN tracks minor and large changes in a huge design file very easily.
BUT ONLY...
...WHEN and IF compression of those binary files is turned off. Compression of native binary source files generally changes the entire binary file, or large swathes of it. Which means SVN will store MUCH larger differences. So ideally the design app allows us to TURN OFF compression for its binary design files.
As it turns out PhotoLine allows us to do just that:
By turning off compression and activating quick saving SVN will track the differences to a BLOBs (binary large objects) only.
Animation software like OpenToonz / Tahoma2D also makes use of SVN for these reasons. The advantage of OpenToonz (or Tahoma2D) is that it already supports SVN directly in the application, which means a simpler and smoother workflow experience for the user (animator).
Blender (3d animation software) also works well with SVN and there is an addon that takes care of (hides) the SVN integration.
*** end of version tracking explanation ***
So how does this actually work in practice? Let's assume we want to work with either a new or existing PhotoLine file and keep track of versions (the history --> create history snapshots).
I assume we are working on Windows here. TortoiseSVN is not available for Macs, unfortunately. SmartSVN or SnailSVN are (paid) alternatives for Mac users. I have not used these myself.
- First we install SVN. Download from https://tortoisesvn.net/
- Install it.
- TURN OFF compression for PhotoLine files in the file save options. Turn on Quick Save ("Fast Saving").
- Follow the quickstart tutorial here: https://tortoisesvn.net/docs/release/To ... guide.html
It would be awesome if PhotoLine would get its own built-in SVN tracking panel, but honestly this falls WAAAY out of the scope of most users' workflow and/or experience here. I am pretty sure 99.9% of PhotoLine users would never make use of it

...which brings us back to your request of a simple history snapshot feature in PhotoLine

For many PhotoLine users a simple history snapshot function would be quite helpful.
Anyway, SVN allow us to take control of version tracking of design projects. It's actually pretty easy to understand and use once you start using it, and I would heartily recommend this to anyone wanting to track versions / history of a larger design project that one is planning to work on. It has saved my butt (and others I work with) many times.
You do not have the required permissions to view the files attached to this post.
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
-
- Mitglied
- Posts: 2370
- Joined: Sat 12 May 2012 21:38
Re: Snapshot in Undo List
PS Addendum
If PhotoLine could save a non-binary text-based PLD format (XML, JSON, or something) and save the bitmap content as individual files alongside that XML PLD file, it would allow ANY version control system to be efficiently used. Including SVN, which still saves rather large difference files.
I am unsure how easy this would be to implement by the Hubers.
...and it would also open up possibilities to use external tools to manipulate those PLD files.
One can dream
If PhotoLine could save a non-binary text-based PLD format (XML, JSON, or something) and save the bitmap content as individual files alongside that XML PLD file, it would allow ANY version control system to be efficiently used. Including SVN, which still saves rather large difference files.
I am unsure how easy this would be to implement by the Hubers.
...and it would also open up possibilities to use external tools to manipulate those PLD files.
One can dream

/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
-
- Mitglied
- Posts: 122
- Joined: Tue 18 Aug 2020 03:07
Re: Snapshot in Undo List
Thanks for all the info Herbert123
Never heard of Git or SVN ... probably overkill for any of the stuff I work / play on.
I mainly use the snapshot tool in the PS history panel when I’m creating actions.
If the actions has many steps ... I like to test it and when one set of steps work, I take a snapshot.
Then if my next set of steps do not work, I can easily get back to my working point.
Just thought it may not be too difficult to add to PL’s user list.
Again, thanks for all the help.
Never heard of Git or SVN ... probably overkill for any of the stuff I work / play on.
I mainly use the snapshot tool in the PS history panel when I’m creating actions.
If the actions has many steps ... I like to test it and when one set of steps work, I take a snapshot.
Then if my next set of steps do not work, I can easily get back to my working point.
Just thought it may not be too difficult to add to PL’s user list.
Again, thanks for all the help.