It is important to understand how dynamic range is handled by this program, for reasons stated below. Dynamic range in a discrete-valued function such as integer-valued pixels corresponds directly to the number of unique values that can be assumed by a particular sample (pixel). For the moment, ignore the fact that color pixels are composed of three independent values, traditionally a brightness value for red, green, and blue. Simply realize that the description given here applies to the red, green, and blue components of an image and its pixels with relatively independence.
So, a single pixel's brightness, say in the red channel, can assume one of a given number of integer values. The range of those values dictates the available dynamic range of the image. What does this mean? Simply put, the dynamic range represents the ratio between the brightest and darkest values that can be registered in an image, so increased dynamic range means an image can represent a wider variation of bright and dark without saturating to pure white at the light end, and emptying to pure black at the dark end. Most common image formats use 8 bits per pixel. They are often called 32-bit images because 8 bits are used for each of the red, green, and blue channels with a 8 more bits left over for reasons of computer efficiency that don't need to be elaborated on here (sometimes they are more accurately referred to as 24-bit images for this reason). The point is, even though they are called 32-bit or 24-bit images, there are actually only 8 bits of information available for the brightness of a pixel in each channel.
The dynamic range is represented as a log value of this range, specifically, log(brightest/darkest). For 8 bits, or 256 possible values, this comes to log(255/1) = 2.4. This is woefully insufficient to represent many astronomical objects such as galaxies and nebulae, which span a much greater dynamic range than this.
Stacking images accomplishes two goals. The first, mentioned on the front page of the documentation, is that it reduces the noise in stacked image compared with one of the original images. The second is that stacking increases the dynamic range. For example, two images summed together, have a maximum pixel value of 510, with a dynamic range of 2.7.
This program faithfully stores the full dynamic range of a stack of 8-bit images. It does this by storing the stacked image using 32 bits per red, green, and blue component, or 96 bits total. This dynamic range would not risk saturation unless you stacked more than 2^24 (16,777,216) individual 8-bit images, not very likely (and then only if some pixel in every image -- the same pixel that is -- had a value of 255). Computers are incapable of producing images on their screens that use more than 8 bits per pixel. Similarly, virtually all known image formats store images at 8 bits per pixel. This means there is no way to truthfully show a stacked image on the screen or save it as a common image file. The image file problem can be solved by saving the stack in a less common image format that can accommodate increased bits per pixel. Two such formats are 16-bit TIFFs and 16 or 32-bit FITs.
To draw the stack on the screen, or to save the stack as an ordinary image file -- an option under the File menu -- the program must project the 32-bit stack down into an 8-bit image. There is nothing complicated about this, but it is somewhat arbitrary. The reason is that a pure projection from 32 to 8 bits would make any realistic stack project into a pure black 8-bit image because even a realistic stacked image uses only a minute fraction of its entire 32-bit range (remember that the maximum number of possible images is 16,777,216, so a realistic stack of, say, 1000 images, uses only the very bottom of the dynamic range). For this reason, generally only a lower subrange of the 32-bits is projected into the 8-bits of the image. The question is, what should that lower subrange be? This is where things become arbitrary, and it is important to understand this section of the documentation because it will help you understand why the program appears to automatically alter the brightness of the stack sometimes.
Stacks are traditionally represented in one of two formats, an average or a sum. An average shows a stack with the same brightness as each of the individual images that contributed to the stack (by dividing the stack's accumulated values by the number of images stacked). A sum shows the stack with a brightness that increases linearly with the number of images stacked (by simply showing the stack's pure values, perhaps saturating to white in pixels that sum to a value greater than 255). However, the stack can in truth be represented by any arbitrary brightness that might be desired.
This program attempts at all times to maximize the use of the 8-bit dynamic range of the projected image when projecting the 32-bit stack into an 8-bit image. It does this by finding the single brightest pixel in the entire stacked image and calculating the necessary divisor to bring that value under 256. Since the brightest pixel will now be divided enough to fit into 8-bits (under 256), all other pixels in the image are guaranteed to fit as well (since they will only become an even lower value after being divided by the same divisor). This divisor changes periodically (usually upwards) throughout use of the program when certain operations may require it to do so. This change will be perceived as a dimming or darkening of the entire stacked image on the screen (since the pixels are being divided by a larger divisor). This should not concern you at the time of the operation that resulted in the dimming of the stack. After the operation has completed you can then use the Histogram/Level Adjustment interface to make the image bright again. The advantage of doing things this way is that the image will not be saturated by such operations that would otherwise max out the pixel values and produce saturated pixels in the image (saturating some pixels would lose valuable contrast information in regions of the image).