An image comparison of Zerene Stacker and Helicon Focus

[Harold Gough]

Rik,

Concentrating on what little I understand sometimes pays off.

Harold

[stevekale]

Steve, I'm afraid you've fallen into the very common trap of elevating RAW to a pedestal that it simply doesn't deserve.

First off, please understand that RAW is not one format, but rather something like 38 different formats. As explained at http://en.wikipedia.org/wiki/Raw_image_format,

Providing a detailed and concise description of the content of raw files is highly problematic. There is no single raw format; formats can be similar or radically different. Different manufacturers use their own proprietary and typically undocumented formats, which are collectively known as raw format. Often they also change the format from one camera model to the next. Several major camera manufacturers, including Nikon, Canon and Sony, encrypt portions of the file in an attempt to prevent third-party tools from accessing them.

Second, the advantages of raw formats are due entirely to their being a faithful representation of what the camera sensor actually saw. Unfortunately, what the camera actually sees is typically a mosaic of RGBG, GRGB, or RGGB values, one color per pixel position, courtesy the Bayer filter that sits in front of the sensor to allow color information to be captured.


Information in Bayer filter format is essentially useless for most photographic purposes.

That's why the first step in digital photo processing is to carefully convert the Bayer matrix pattern that the camera actually saw, into a traditional RGB or LAB representation in which the same type of information is stored at each pixel position.

This I am fairly well versed in. My point was directed at the time and CPU efficiency of converting just one RAW final (the final one) and managing smaller file sizes. Of course, you would need a RAW converter embedded in ZS to be able to render the images for editing, but I was thinking there would be efficiencies to keep the files in the RAW domain.

There are also many moves afoot to standardise the file system for RAW, including those by Adobe. (Also, Adobe is steadily in the process of converting Photoshop to a completely RAW domain. They must see advantages to such and there's been much discussion about some of these eg sharpening in RAW.)

Now perhaps you see the issues more clearly. Not only are there a bunch of different and incompatible raw formats, but almost all of them are simply terrible for operations needed for stacking, such as small changes in shift/scale/rotate needed to align stack frames. The only reasonable way to do stacking from raw is to convert first, then stack the converted results.

I will leave this side of things to you - whether you need a colour assumption to perform such tasks I don't know. I would have thought not for many, eg alignment.

At some point Zerene Stacker will probably provide direct input of raw images too. But when it does, the implementation will be just the same as Helicon's: behind-the-scenes conversion to RGB for the sake of user convenience.

This I wouldn't bother with.

BTW how many users here have taken the time to profile their cameras for Adobe ACR? I suspect not many.

I do own a Wacom Tablet (bought for testing), but quite frankly I've never spent the time to get good at using it.

Once you head that way you'll never go back. I don't know how anyone can do serious retouching with a mouse - just too painful.

I apologize for the inconvenience. Whether you switch tools is entirely up to you, of course, and the tradeoffs depend on what you want to do.

I may well be making the switch faster than anticipated!

[Chris S.]

Zerene Stacker is a stacking tool. It is not designed as a viewing tool except as needed to support retouching, and it has no capabilities to adjust contrast, brightness, or color balance. As a result (it seems to me), the lack of color management during display has pretty small effect on its operation. At least that was the case in my tests. If I'm wrong about that judgment, then more information and discussion would be most appreciated.

As a Zerene Stacker user, I give the current approach a thumbs up. Since ZS preserves the color profile of the input images in the stacked output image, I wouldn’t describe ZS as being “not color managed.” I'd say that Zerene Stacker takes a highly efficient approach to color management, in preserving color profiles without wasting resources on fancy display. If wide-gamut color display were available in ZS, and turning it off would shave a couple of minutes off a thousand-image stack, I would turn it off. My colors might look less vivid during stacking: No problem--I take all my stacks to Photoshop, where I apply a curves adjustment and other modifications. Since I have wide-gamut color representation when applying curves, saturation, and other modifications appropriate to pixel editing, why would I need it during stacking?

Importantly, processing resources are not the only issue; from what I know of software development, support/enhancement chores always need to be prioritized. Whenever something is moved forward in the queue, other things have to move backward. This item would rate very low on my priority list. We should be careful what we ask for, as we may get it—and in so doing, sacrifice things that might offer more benefit.

Ditto for having Zerene Stacker muck around with raw files. If I understand this discussion, Helicon can do a quick and dirty conversion from some raw formats, based on a set of default assumptions. If so, any benefits offered by raw formats are lost. I’d rather shoot a good set of jpegs, stack them, and save the output as a TIFF file. This way, the jpeg is made in camera, via processing steps tuned by the camera engineers to match the camera. More importantly, I can view and tweak sample jpegs prior to image acquisition, resulting in a very good jpeg, as interpreted by me, the photographer.

To those with a superstitious dread of jpegs, this approach often produces quite good results. I usually capture both raw and jpeg versions of each shot, and prefer the raw only when the dynamic range of the subject pushes the boundaries of what a jpeg can hold. This occurs often in the field, but much less frequently in the studio. In those cases, I’m going to carefully adjust a raw file (I usually pick one from near the center of the stack), and run the conversion in batch based on the needed settings. The many tweaks available in a good raw processor are what makes raw files sometimes better. Is it likely that any default-based raw converter would provide anything like what I can do in a few minutes on my own? I don’t think so.

While it would be great if camera makers agreed on a common raw format, I wouldn’t look for it to happen soon—maybe sometime after the abolition of death and taxes. And different raw conversion applications produce quite different results—for me (a Nikon shooter), Nikon’s Capture NX2 provides markedly better conversions than Adobe ACR, Bibble, or other programs that I’ve tried. Opinions differ, of course—but my point is that programs that specialize in raw conversion vary in quality of output, so raw conversion is by no means a generic process. So there is no way I’d expect a stacking tool, no matter how good, to compete with dedicated raw conversion programs at their own game. And from what Rik says, and what little I understand of raw formats, a “pass through” approach to raw formats (as Zerene Stacker uses for color profiles) seems wildly impracticable.

--Chris

[stevekale]

I don't want to turn this into a huge tangential debate. I agree that colour management isn't critical to the stack-editing component. I just don't believe it would add minutes or even seconds to any process. The only computation is the image file to display translation.

I would never rely on in camera RAW conversion to JPEG processing. It is not at all designed for accurate colour rendition.

You miss my point re RAW. I wouldn't want a "default" RAW converter in the stack software. I would hate that and don't like HF's implementation.

The annoying thing today about someone wanting to shooot in RAW and manage the RAW-TIFF (or PSD or JPEG) conversion (for whatever reason) is that they if they wish to revisit the RAW conversion work they have to redo all the stacking software work. So - if a colour rendering isn't necessary for the stacking software (other than for the display) - a big if - it would be great for the image stacking/alignment and stack-editing to remain in the RAW domain and for a RAW file to be delivered back to the user (not a processed RGB file).

Put another way, this requires the stacking software to be able to work in black and white (as a RAW file is merely a 16 bit file of measurements, typically recorded in-camera at 8 or 10 bits, of the level of photons hitting a pixel well - it's colour blind). If it can, then there's likely no need for RAW conversion to do the stacking. (To be clear, of course the file needs to be converted for intermediate display but it's likely even the system software can do this; at least for Apple.)

Re different RAW formats, Adobe DNG would cover a lot of ground.

[rjlittlefield]

The annoying thing today about someone wanting to shooot in RAW and manage the RAW-TIFF (or PSD or JPEG) conversion (for whatever reason) is that they if they wish to revisit the RAW conversion work they have to redo all the stacking software work.

I agree, very annoying. Staying in RAW is an enormously attractive thing to want to do.

So let's take a few minutes to talk about the details of why we do things the annoying way and not the attractive way.

Following are several views of the same image in two different representations. On the top of each pair we have ordinary RGB, the result of Photoshop's conversion from raw. On the bottom we have the corresponding raw data, simply converted pixel by pixel to grayscale (using dcraw's -d option).

50%


100% (actual pixels)


200%


If you stand back and squint, as in the 50 percent view, then indeed it makes sense to think of the RAW image as being simple monochrome.

However, when you go closer and try to resolve pixel level detail, then the essence of the RAW format becomes more clear. Thinking of the RAW image as simple monochrome does not work at this level. Actually the RAW image is three different monochrome images interlaced pixel by pixel, and information about both color and fine details of luminance are distributed across all three images.

It's worth looking specifically at the upper left corner, where we have completely featureless yet intense blue background. In this area, the blue-sensitive photosites have large values while the red- and green-sensitive photosites have small values.

If you treat this area as monochrome, ignoring the Bayer pattern, then it appears to be loaded with fine detail at the pixel level. In fact this area has stronger "detail" than anywhere else in the image. Only when the Bayer pattern is taken into account -- when the RAW image is converted -- does the featureless but colored nature of the region become evident.

Further, what makes the area "blue" is the fact that only the blue-sensitive photosites have large values. Any image manipulation that changes the alignment of values and photosites will change the color and perhaps even add or subtract detail. Shift by a full pixel position in one direction and the featureless intense blue turns into featureless intense red. Shift by a full pixel in a different direction and the featureless intense blue turns into a finely textured intense green, as only every 2nd green photosite gets a large value, while each 1st green photosite is still small. Shift by a partial pixel in any direction, and the colors just get weird.

Earlier, I wrote that most RAW formats are "simply terrible for operations needed for stacking". Perhaps now it's more clear what I was talking about. Information about presence or absence of pixel-level detail is not immediately accessible in the RAW representation, and if you shift or scale by anything other than exact multiples of 2 pixels, the colors get messed up. Stacking is all about shift & scale to line things up, followed by identifying and preserving focused detail, and the RAW representation doesn't work for either of those. Serious bummer.

Put another way, this requires is for the stacking software to be able to work in black and white (as a RAW file is merely a 16 bit file of measurements, typically recorded in camera at 8 or 10 bits, of the level of photons hitting a pixel well - it's colour blind). If it can then there's no need for RAW conversion.

I hope you now see the lapse in that line of reasoning.

Stacking software has no trouble working in black and white. Put a monochrome stack in the top and you'll get a monochrome stacked result out the bottom, no problem.

But stack a bunch of RAWs as if they were monochrome, and you'll get junk. Treat that junk as a RAW image to be converted, and the situation only gets worse.

To stack images from RAW format, they have to go through that process of converting the Bayer grid representation into some ordinary luminance/chrominance representation where the information that's needed for stacking becomes available in the representation. The thought of staying in RAW may be attractive, but it doesn't work.

On the other hand, since staying in RAW is attractive, maybe it's worth thinking carefully about why that's attractive and what might be done to enable the same benefits but in a different representation that's still compatible with stacking. Linear color spaces come to mind, but given the length of this post, I think I'll leave that for another day.

--Rik