Zerene Stacker Known Issues
Known Issues is a list of unusual problems that have been reported typically one to three times, but may be seen by other people too.
If you encounter difficulties that are not on this list, or if the suggested workarounds do not work for you, then please contact support@zerenesystems.com. We try hard to fix problems, but we have to know about them first!
Here is an index to the known issues:
License keys that contain accented or non-English characters may get corrupted in email transmission
If the username in the license key looks odd, and the Enter button stays gray when you paste in your license key, try just retyping the name to match what you entered when you purchased the license. Further details are provided in How To Install a License Key.
If that doesn't work, then please contact support@zerenesystems.com and we'll get the problem taken care of.
Settings are retained across uninstall / reinstall
On Windows, the uninstaller program removes only folders and files that it created. This causes some state information to be retained, so that uninstall/reinstall will not restore the program to a factory-fresh condition. To get back to a factory-fresh condition, you must uninstall, then manually remove one folder and the files it contains, before reinstalling.
The folder you need to remove is in the “application data” area of your profile. Go to Start > Run and open %appdata%. This will open a Windows Explorer to view a directory named something like “C:\Documents and Settings\username\Application Data”. Within that directory, select and delete the folder named ZereneStacker.
On Macintosh OS X, dragging the application bundle to the trash leaves behind some state information in other files and folders, so that reinstalling the program will not restore the program to a factory-fresh condition. To get back to a factory-fresh condition, you must manually remove one folder and the files it contains, before reinstalling. The folder you need to remove is ~/Library/Preferences/ZereneStacker, where ~ denotes your account's home directory. Be careful that you do not remove other folders in ~/Library/Preferences, as these contain settings for other programs.
On Linux, it is the same situation except that the folder you need to remove is ~/.ZereneStacker (note the dot – this directory is normally “hidden”).
License key must be installed for each user account
If the product is licensed for multiple users, each user will need to install his or her own copy of the license key. Until this is done, each new user will see Zerene Stacker as running in Trial Mode.
On Windows, each user will also need to set memory allocation. On Macintosh, memory allocation is maintained in a different way that makes one setting apply to all users.
External TIFF reader cannot handle commas in file or directory names
The external TIFF reader erroneously truncates the file name or path at the first comma. This error results in a generic “Uh-oh – something went wrong” popup, with diagnostic details in the console log that go something like this:
Trying to read /Users/zstest/ImageFiles/stuff, etc./TIFF/IMG_2575.tif
...
From external converter error stream: TIFFOpen: /Users/zstest/ImageFiles/stuff: Cannot open.
com.zerenesystems.stacker.a.o: Tried but failed to read /Users/zstest/ImageFiles/stuff, etc./TIFF/IMG_2575.tif using external converter.
Notice the truncation of “ImageFiles/stuff, etc./TIFF/IMG_2575.tif” to be just “ImageFiles/stuff” in the error message.
Certain grayscale images may cause "incompatible ColorModel"
Some grayscale images may cause Save Output Image(s) to fail with a diagnostic like this:
java.lang.IllegalArgumentException: Raster ShortInterleavedRaster: width = 1504 height = 1242
#numDataElements 3 is incompatible with ColorModel ColorModel: #pixelBits = 16 numComponents = 1
color space = java.awt.color.ICC_ColorSpace@5c3f1224 transparency = 1 has alpha = false isAlphaPre = false
at java.awt.image.BufferedImage.<init>(Unknown Source)
The workaround is to select Options > Preferences > Color Management > “Do not manage color”.
ZoneAlarm Toolbar may significantly reduce available memory
Simply installing the ZoneAlarm Toolbar may reduce the maximum Zerene Stacker memory allocation by several hundred megabytes. This is due to address space fragmentation caused by one of the ZoneAlarm's DLLs (ISWSHEX.dll, hard-loaded at address 0x20cb0000) . ZoneAlarm has been notified of the problem, but at present their only workaround is to un-install the Toolbar.
Update: In the latest release of ZoneAlarm Internet Security Suite version 10.0.250.000, even removing the Toolbar is not sufficient — ISWSHEX.dll is loaded anyway. We are not aware of a workaround in this latter case, except of course to uninstall ZoneAlarm and use a different security product that avoids such application-unfriendly behavior.
Added physical memory is not seen by Zerene Stacker
If you add physical memory to your computer after running Zerene Stacker, the added memory will not be seen automatically by Zerene Stacker.
To correct this problem, simply go to Options > Preferences > Memory Usage. First press Detect, then press Set Automatically to determine the maximum amount of memory that the computer will allow Zerene Stacker to use.
In the unlikely event that added physical memory is still not seen, or if the automatically detected value is not correct, then enter the proper value by hand before pressing Set Automatically.
In versions prior to T201001162110, the workaround for this problem was to manually edit a configuration file. We strongly recommend upgrading to a current version.
How to find and remove "orphaned projects"
To find orphaned projects, simply search your disk for directories or folders whose name begins with “unnamedZSproj”. The full name will be something like “unnamedZSproj20090707122911640”, where the trailing digits are a timestamp (year, month, day, etc). Remove these directories and all their contents. On Windows, you will have to select the option to “include hidden files and folders” so that the Windows Explorer Search function will find projects in the system's temporary directory where they are normally placed.
The underlying issue here is that if Zerene Stacker crashes or is aborted by the operating system while it has image files loaded, then the project it was working on will be retained on disk and may consume significant space. If the project had never been saved to a specified location, it is likely to be located in a directory of temporary files where it won't be obvious. Especially on Windows, these orphaned projects may be retained for long periods, since the operating system does not clean up temporary files very often.
To process large images at full resolution, you must increase the memory allocation above the default values
When you Add File(s), you may receive a popup window that looks something like the following:
If you proceed without pre-sizing and without increasing the memory allocation, then you are likely to encounter the following error (“Out of memory, cannot proceed”):
If your computer is large enough, then the cure for this problem is to allocate more memory using Options > Preferences > Memory Usage.
Very large images (above 21 megapixels) may require using the 64-bit version of Zerene Stacker, on a 64-bit operating system.
Continuous backup or indexing may interfere with image caching
Some backup and indexing facilities have the unfriendly behavior of briefly grabbing a file in exclusive-access mode immediately after it is created. This can interfere with Zerene Stacker's caching of image files, because ZS often attempts to read these files immediately after they've been created, and if another process has grabbed them, it can't.
The problem appears as a red “Uh-oh” popup, with a detail diagnostic like this:
java.io.FileNotFoundException: C:\Users\Me\Pictures\unnamedZSproj20111103154858382\previewimages\-Unaligned-117.jpg (Access is denied)
at java.io.RandomAccessFile.open(Native Method)
There are several possible workarounds for the problem:
- Turn off or pause the backup or indexing facility while ZS is running.
- Configure the backup or indexing facility to have a longer delay between file creation and backup.
- Configure it to not backup or index some specified directory, then in ZS use Options > Preferences > New Projects to place new projects in that directory.
- In ZS, go to Options > Preferences > Image caching, and un-check both options. This will make the initial stacking go somewhat faster, but will make subsequent reviewing and retouching much slower. In addition, this option still leaves open the same sort of vulnerability on the .zsy files that are used to store output images.
On Windows, if the problem is caused by an indexing plugin, then one way to work around the problem is this:
- Click Start > … on the Windows taskbar.
- Type “services.msc” into the Open box, then click OK. “Services” panel will pop up.
- In the Services panel, scroll down and select Windows Search. The Description will say “Provides content indexing, …”.
- In the upper left part of that panel, click on “Stop the service”.
- Run your stack.
- Back in the Services panel, click on “Start the service”.
Windows, "My Documents" and "My Pictures" may not be writable
On some Windows systems, special folders such as “My Documents” are erroneously marked as “Read Only”. Most applications never notice, but Zerene Stacker honors the “Read Only” status for these folders and refuses to create files or new folders in them.
One cure for this problem is to use an arcane Windows command to clear the “Read Only” status for those folders. Simply open a Command Prompt window (using for example Start > Run… > cmd), then type the following commands:
attrib -r "%USERPROFILE%\My Documents"
attrib -r "%USERPROFILE%\My Documents\My Pictures"
It is only necessary to run these commands one time.
Alternatively, you can use Windows Explorer to create new folders, which Zerene Stacker can then write into.
Windows, cannot navigate through a shortcut
On Windows, the filechooser dialogs popped up by Zerene Stacker may not be able to navigate through a shortcut. This is due to a bug in the Java Runtime Environment. The problem is diagnosed by a generic “Uh-oh – something went wrong” popup, with a red-highlighted error message in the console log like this:
Exception occurred during event dispatching:
java.lang.InternalError: Unable to bind F:\ZereneSystems\TestStacks\FruitFlyFace - Shortcut.lnk to parent
at sun.awt.shell.Win32ShellFolder2$4.call(Unknown Source)
There are two workarounds: either access your folders using a path that does not involve a shortcut, or where possible use drag-and-drop.
Macintosh OS X, how to recover from excessive memory allocation
Under most circumstances, the Options > Preferences > Memory Usage control panel will prevent you from specifying a larger memory allocation than your computer can actually support. Under unusual circumstances it is possible to specify too large a value. In this case, subsequent launches of Zerene Stacker will fail with some diagnostic like “The application ZereneStacker quit unexpectedly.”
The simplest cure for this problem is the following: Download and install a fresh copy of Zerene Stacker. Launch it. You will receive a diagnostic popup that says “Memory allocation has been reset following a software update. You must exit and re-launch the application to use the new allocation.” Do not exit the application at this time! Instead, proceed to Options > Preferences > Memory Usage, click the Set Automatically button, then click the OK button. Exit the application, re-launch, and everything should be fine again.
In very rare cases, the re-launch may fail because the computer cannot allocate the amount of memory that the Set Automatically button requests. If this occurs, then repeat the previous procedure, but instead of clicking Set Automatically, simply type the value 1000 into the field labeled “Megabytes of memory currently allocated to 32-bit Zerene Stacker”. Click OK, exit, and re-launch.
Macintosh OS X, the downloaded bundle runs once but not again
This extraordinarily puzzling problem, reported on four systems to date, has the symptom that a downloaded bundle runs fine once, but on subsequent launches it aborts immediately with “The application ZereneStacker quit unexpectedly” even though there is no problem with memory allocation.
The root cause of this problem turns out to be that the Mac operating system has somehow modified or replaced a JavaApplicationStub that is provided with the bundle. The modification/replacement happens on first execution, which is why Zerene Stacker works once but not after that.
In the long term, we will change the Zerene Stacker bundle to use a different first-execution procedure to avoid this problem.
But as a short-term workaround, it has proved adequate to replace the JavaApplicationStub in Zerene Stacker with one that should already be found on your system. Here is the procedure:
The file to be replaced is at ZereneStacker.app/Contents/MacOS/JavaApplicationStub . To reach into this directory, simply right-click (or ctrl-click) on the ZereneStacker icon, then select Show Package Contents. Navigate to Contents/MacOS, and you will see the file JavaApplicationStub.
The JavaApplicationStub that you need to use instead can be accessed using Finder. Open a Finder window and go to <bootdisk>/System/Library/Frameworks/JavaVM.framework/Resources/MacOS, where <bootdisk> is just the name of the disk that you boot from. There you will see one or two files, JavaApplicationStub and possibly JavaApplicationStub64.
Right-click on the JavaApplicationStub in the …Frameworks… tree, and select Copy “JavaApplicationStub”.
Then go into Contents/MacOS of the ZereneStacker package, right-click on any blank space, and select Paste Item. You should receive a warning that “JavaApplicationStub” already exists. Go ahead and allow the replacement, after looking one more time to be sure that you really are inside the ZereneStacker package and not still in Frameworks.
Macintosh OS X, accessing external drives may be awkward
Note: In all recent versions, you can drag-and-drop directly onto the input files list. There is no need to File > Add Files to open a filechooser as described below.
The Java filechooser currently used by Zerene Stacker does not display alternate volumes like the native Mac filechooser does. External drives can still be accessed, but the procedure is somewhat awkward.
On OS X 10.5 (Leopard), the easiest approach is to open a filechooser dialog box in Zerene Stacker, using File > Add Files. Then separately, use Finder to open the external drive or network share, go to the appropriate directory, and select the files of interest. Drag and drop those files onto the Add Files dialog of Zerene Stacker, then click the Add button in the Zerene Stacker dialog. This method also has the advantage of showing you a thumbnail preview of the files to be added.
Alternatively (and required for OS X 10.4), you can go to the bar at the top of the window, the one where the current directory is shown. Click once on that bar and it will expand into a pull-down list of enclosing directories. At the bottom of the list will be an entry like “Macintosh HD”, representing the main file system of the computer. Click that. Scroll to the bottom of the list and double-click on Volumes. That should give you a list of all your currently mounted media. Double-click on any external drive to open that, then navigate as usual.
The latter approach is required on OS X 10.4 because drag-and-drop into the Zerene Stacker filechooser does not work on that system.
Macintosh OS X, launch fails due to Courier font problems
Zerene Stacker may fail to launch on Mac OS X due to font problems. A typical message appearing in the system console log is:
Warning: the font "Courier" is not available, so "Lucida Sans Typewriter" has been substituted, but may have unexpected appearance or behavor. Re-enable the "Courier" font to remove this warning.
Check in the font manager to be sure that you have exactly one Courier font installed and active. Despite the phrasing of the message, having two or more Courier fonts installed is also a problem.
Macintosh OS X, TIFF files may be very slow to read
On PowerPC systems, most TIFF files are slow to read and 16-bit TIFF files are particularly bad. At this time the only workaround on PowerPC systems is to make copies of your TIFF files as highest quality JPEG, converting 16-bit to 8-bit if necessary, then stack the JPEG copies.
Intel Macs should read TIFF files quickly (seconds per image), if Options > Preferences > Preprocessing > Use External TIFF Reader is selected. This is the default setting. If this option is not selected, then some types of TIFF files will read very slowly (minutes per image), although well-behaved TIFF files will read somewhat faster than with the default setting.
Macintosh OS X, JPEG files with color profile "Nikon sRGB 4.0.0.3001" will be dark and muddy
The root cause of this problem is unclear. Such files read OK on Windows, but not on Mac. One workaround is to use Photoshop or some other image editing tool to remove the profile entirely, or to assign or convert the profile to sRGB (“sRGB IEC61966-2.1”), which appears to be an equivalent profile with a different name. TIFF files with the Nikon profile are read correctly.
Linux, use of native Look & Feel with Ubuntu Studio theme fails
Selecting the native Look & Feel, while running with the Ubuntu Studio theme, causes several problems ranging from improper screen format to red “Uh-oh” exceptions. This appears to be due to problems in the Java runtime system, specific to the Ubuntu Studio look & feel.
The workaround is to select “Java cross-platform Look & Feel” at Options > Preferences > Look & Feel.
Very large TIFF files may require "Use External TIFF Reader"
On 32-bit systems, large TIFF files may provoke a bug in the Java runtime system that is diagnosed like this:
Trying to read <filename>
Exception occurred during event dispatching:
java.lang.OutOfMemoryError
at java.io.RandomAccessFile.readBytes(Native Method)
The threshold for “large” depends on circumstances. Most often it is around 70 MB, but even much shorter files can cause problems on some systems and workflows.
If you encounter this error, go to Options > Preferences > Preprocessing and place a checkmark to select “Use External TIFF Reader”. This uses a different method of image reading that bypasses the Java runtime bug.
Recent versions (T201108020545 and later) automatically fall back to Use External TIFF Reader if this bug is encountered.
Red "RasterFormatException" occurs during retouching
On some systems, the following error occasionally occurs during retouching:
java.awt.image.RasterFormatException: negative width
The problem seems to be related to both the computer system and to the style of retouching. This problem is believed to be fixed in releases at level T201009091815 and beyond.
Graphics "acceleration" sometimes makes the retouching brush very slow and jerky
This problem is believed to be fixed as of version 1.02 build T201008081620. Please let us know if you encounter it again!
As a workaround in earlier versions, simply turn down the setting for graphics acceleration on your video card. On Windows XP, the recipe is Start > Control Panel > Display > Settings > Advanced > Troubleshoot tab > Hardware acceleration, move slider and Apply. At a setting of None, the brush should move smoothly, with several updates per second even when the brush is a hundred pixels across. Try that so you can see how it works, then select the highest setting that works that well or better.