The politics behind this decision to kill CNX-2 may be varied and wide ranging, least of all the "U point" technologies previously licensed by Nik software being acquired by google. CNX-D is based/rebranded on the 3rd party silkypics but in comparison many features were dropped. Editting in CNX2 can be broadly categorised in 2 areas - modifications made to the RAW data (the "develop" section, including exposure quickfix and WB) and then adjustments made at the pixel level (the "adjustment" section, including cropping, straigthening, auto touch up brush).
The main issue is that CNX-D does not to honorthe the saved CNX2 modifications if ANY adjustment steps have been added to the saved NEF - CNX-D will happily open RAWs that have only had WB and exposure modifications made, but a single adjustement step added to the NEF will result in CNX-D reverting to the original NEF data. Furthermore, CNX-D does not have the ability or option to re-save embedded thumbnail with results of NX-D mods (ie - the inability to remove D800's 17mb embedded jpg that's in every D800 NEF with a smaller one - a feature CNX2 introduced to address this specific point) since it does NOT save to the NEF file but instead writes it's modifications to proprietary side files.
With the announcement that CNX2 will no longer be supported after the first public release (at time of writing, CNX-D is still in beta) long time CNX2 users, with their libraries of thousands of modified NEFs, will have to worry about future proofing their access to their libraries. Whilst 'no longer supporting' may mean many things that you'd expect (no bug fix, no new cameras NEFs compatible and in fact the lastest CNX2 release, 2.4.7, has already removed direct support for WinXP (2.4.6 being the last supported WinXP version), it will probably also mean the license server will die that may ultimately prevent users from future installs of CNX2.
In the modern day computing, the solution would be in virtualising their current working environment (OS + installed/licensed CNX2) and then making critical and multiple backups. But which option for virtualisation?
virtualbox and vmplayer are the major (free) candidates for this and then the options are:
- p2v their current running OS
- create from scratch a virualised image from OS install media
- use a pre-virtualised disk image in the virtualiser
Previous experience of p2v (for vmplayer with their converter software) was succesful but it created an virtual disk image that was the same size as my hard disk partition (80GB) which isn't very useful given most of the space is empty. There were tools that appear to be available in their non-free VMware products. Similarly, the p2v instructions for virtualbox are fairly complex and also look like it's just an image dump.
Creating a new virtual machine and disk image (install from scratch) is a nice clean option.
However, Microsoft do provide a prebuilt virtual image of their 32bit WinXP Professional for use with their Win7 virtualiser - from the .exe file you will need to extract (via WinRar or equivalent) the file called "xpm" which is a rar/zip file containing a the virtual disk image "VirtualXPVHD" - extract and add a .vhd extension which can then be opened by virtualbox; the current vmplayer (v6.0.3) will not be able to read this as it's only a virtual disk image - previous versions appeared to have the functionality to import but this is missing in version 6 although it appears to be available in the paid VMware products. There exists WinImage that allows you to convert a VHD to a VMDK (vmware) disk image and is painless - however, ensure that when converting to create a dynamically expanding/sized disk - this will ensure that whilst the virtual disk image represents a 100GB partition, the dynamic virtual disk only uses up what is required otherwise a 100GB VMDK will be generated by WinImage.
Be warned that the WinXP Professional image needs to be activated so unless you have a retail (not OEM) product key, using this method may be wasted effort. Furthermore, because it is only a 32bit system, the max memory supported is 4GB along with 2x CPUs no matter the configuration of the host OS.
Once a running guest OS is successfully installed, proceed with the CNX2 installation.
It has always been said that CNX2 uses an activation/license server but I was able to remove networking for the guest OS and still able to enter the product key and have the software become 'registered'. With the resulting guest OS fully configured, it is now to disable all internet networking except for the internal shares to allow the guest OS to access the NEFs that will remain on the host.
For all virtualbox installations, it appears that the networking requires a little bit of admin.
I went with the virtualbox route in the end using an WinXP installation and the resulting single virtual disk image was a very reasonable 2.9GB (compared to a 37GB virtualised Win7 x64 with CNX2 image) - such an full installation can be easily backed up to ensure that when the current h/w hosting my working CNX2 dies, I'll be able to resurrect CNX2 from dead via virtualbox - assuming that virtualbox itself doesn't become end of life.
No comments:
Post a Comment