Feature Request: Optionally ignore or show only alpha in Picture Compare

[pbrown]

I've just upgraded to the BC4 beta and am really happy with the changes there across the board. I have one issue in my workflow that the picture compare tool in all of the Beyond Compare products doesn't quite work for, and it would be really sweet if a tweak were possible.

I find myself frequently needing to diff large collections of PNG images that include an alpha channel. These images are obtained from framebuffer dumps and don't necessarily have the property that the alpha channel should be interpreted as opacity. BC4 currently displays images without full alpha (0xFF) as a blend between the RGB pixels in the image and a checkerboard image. This behavior means that the images displayed in the picture comparison tool don't look anything like you'd see on-screen. I can understand why people would want the current behavior, but it would be nice to have additional options here.

The controls I find useful in this area in other purpose-built tools I sometimes use are:

(1) A control to disable or ignore transparency entirely. This is the default in BC2. I think this is what BC4 would produce if the alpha channel were 0xFF in all pixels.

(2) A control to display the alpha channel as grayscale, which would let you see differences in the otherwise invisible alpha channel.

I currently use BC2 to manage these image collections, because the transparency in BC3/BC4 makes images possible to compare. However, BC2 lacks other useful features (like peeking at individual pixels - a great addition to BC4), and sometimes I have to switch to a different picture comparison tool to compare images and then switch back to BC2 to update my collection. It would be great if I could do everything I need in BC4, and the current version seems pretty close.

[Aaron]

Thanks for the suggestion. It's on our wishlist to expand our alpha channel comparison and options, and I'll add these notes. Do you have a pair of sample files you'd like to include with how you'd like to compare them (2)? I can add the examples to our wishlist entry as well. You can email them to [email protected], with a link back to this forum thread for our reference.

[pbrown]

Aaron, thanks for the quick response. I've passed along sample images to the Scooter Software support email address you provided.

[Zoë]

What kind of data is usually stored in the alpha channel for the images you're comparing? The samples you provided look correct either with or without the alpha blending. Is it random garbage, depth values, normals, etc?

We have discussed/planned for more control over the different channels, but it definitely won't make it into the initial v4 release and we have some other projects that will take time after that. Short term you should consider using something like ImageMagick to strip out the alpha channels automatically. The picture compare supports external conversion file formats, so you can set up a "PNG no alpha" format that does the conversion and just select it when you need it.

[pbrown]

A little bit more about my use case. I work on 3D graphics hardware/drivers, and have a set of tests that work like:

- create a window with an RGBA framebuffer
- run a 3D program doing whatever it wants to that RGBA framebuffer
- read back the RGBA channels of the framebuffer as-is
- see if the RGBA image matches a previously reviewed images

In this environment, the RGB contents of the window are displayed on-screen, and the alpha is typically irrelevant from the user's POV. We do still store and compare alpha values since a change in alpha values might indicate a bug affecting similar tests.

The actual values stored in the framebuffer come from whatever the app tells us to do. Often times, the values are garbage (from using math on all four channels that makes sense with RGB, but not alpha). Sometimes, there is a pattern that makes sense (e.g., background = 0, foreground = 255). In any event, the alpha that is present often doesn't fit the standard "transparent PNG" model that the current picture compare tool implements.

Stripping alpha as a preprocessing step doesn't quite work for my workflow, which goes like this:

- start with a folder of "known (or suspected) good" images
- build a folder of "new" images that don't exactly match the "good" ones
- compare the two folders, updating the ones that don't match
- copy "new" images to "known good" if they pass inspection

If I strip out alpha before comparing, the copied images would still have alpha stripped out and couldn't be used for future exact match comparisons that include alpha. The transparency support in BC3 and BC4 for images makes the inspection part hard, so I am using a BC2 to manage the directory updates and a combination of BC2 (with its lack of alpha support) and external tools to inspect image changes.

[Zoë]

Ok, thanks for the additional information.

I wasn't suggesting batch removing the alpha channel. In Beyond Compare's "File Format" settings you can set up an external conversion which is run as part of the comparison and works on temporary files. The originals aren't modified. Take a look at the "EXIF headers" format on our Additional File Formats page for an example of how it works and how to set it up.

[pbrown]

Oh, thanks -- I'm pretty sure I understand.

With this external conversion operation and a new "File Format" rule, I could configure BC4 to diff .PNG images as though the alpha channel weren't even there (like BC2 would do). But when I approve changes, I'll be copying the unfiltered files with the original alpha data there. That approach seems like it would operate as though my proposed feature (1) were turned on all the time.

I suppose I could turn the feature on and off by toggling the enable for the new file format, though leaving conversions on full-time suits my purposes pretty well. (I suppose I'd still have to shell out to see the original alpha values.) I assume that there's no easy way to do this programmatically? I couldn't see anything relevant in the scripting reference.

That might be worth investigating.

[Aaron]

Hello,

The conversion would only occur when you view the files in the Picture Compare. If you perform a copy from left->right, then that would just copy the file. How would you 'approve' your changes?

[pbrown]

Hello,

The conversion would only occur when you view the files in the Picture Compare. If you perform a copy from left->right, then that would just copy the file. How would you 'approve' your changes?

The way I do it with BC2 now is:

- Open directory comparison with "new" folder on the left, "good" folder on the right, with "left newer and orphans" view.
- Open the first image difference in the picture comparison tool to see if new image is good.
- Repeat for more image differences (Ctrl-M to jump to next file).
- Copy any good images from left to right.

Applying the external conversion step suggested by Greg should work in this flow just fine, other than having no way to inpect the alpha channel inside BC4.

[Zoë]

ImageMagick has lots of different conversions you can use, including extracting the alpha channel as a grayscale image. Here are the steps you'll need to do everything:

1) Create a new picture file format "No Alpha" with whatever you need as the mask (e.g., "*.png"), and this as the external conversion command line:

"C:\Program Files\ImageMagick\convert.exe" %s -alpha off PNG:%t

2) Create another new picture file format, "Alpha Only", with an empty mask and with this as the external conversion command line:

"C:\Program Files\ImageMagick\convert.exe" %s -channel A -separate PNG:%t

3) If you only want the "No Alpha" format to apply to certain folder compare sessions you can selectively check/uncheck it in the Folder Compare's Session Settings dialog, on the "Misc" tab.

4) When you have an image loaded and you want to see the alpha channel, click the "Rules" button, switch to the "Format" tab, and select "No Alpha" from the "Left" and/or "Right" dropdowns, then click "Ok".

That last step is a bit convoluted because the picture compare doesn't currently have the "Format" dropdown on its toolbar, and we'll look into changing that.

Also, the "PNG" bit in the command lines is the target format for the output file. "BMP" should theoretically work, but I just found a bug in the BMP autodetection that's preventing that.

[pbrown]

Craig,

Thanks for following up. I got the opportunity to try out the workaround you propose and it works quite nicely.

A few other comments:

1) I didn't find any "Misc" tab in the Folder Compare's Session Settings dialog in 4.0 (build 18746). I have "Specs", "Comparison", "Handling", "Name Filters", and "Other Filters". None seem relevant to this setting.

2) One nice feature of some of the purpose-built tools I use is having a quick image difference report on the status bar (reporting number of pixels different and maximum difference in R/G/B/A). Having the maximum difference at your fingertips is useful for quickly identifying "LSB" differences, where a minor change in computation could produce an R value of 123 instead of 124. This is the same sort of thing that BC's "tolerance mode" has picked out.

3) The "tolerance" display mode seems to be somewhat broken in the current build. When I bring up two images that are clearly different, the status bar shows "= Same" even though the images are obviously different and the difference window shows differences clearly. This happens with or without ImageMagick conversions enabled, and no matter what the tolerance is. The other display modes properly say "Important Differences".

4) I can't quite wrap my head around what the image in the tolerance mode is actually supposed to be doing. By default, it seems to put up shades of blue and red for differences below and above the tolerances, with brighter colors, which is nice. "No differences" seems to be colored gray (also fine).

The thing I find somewhat distracting in this mode is that all colors seems to be shaded based on the colors of the pixel in the original images. If I compare two identical images with white text on a black background, the difference image is gray for the background part and white for the text part. However, I also compared identical images with a multi-colored triangle on a green background (like the image I emailed you), and that shows up with a fully gray background with no color highlights. I'm not sure what to make of that.

I'm not sure I'd use the tolerance mode even if it behaved more like I was expecting; I'll probably use "Mismatch Range Mode" most of the time.

Thanks for all your help!

[Aaron]

Hello,

Thanks for the feedback.

1) The Misc tab assumes you are using Pro edition. Unfortunately, you wouldn't have access to this tab with Standard mode.

2) Thanks for the suggestion. Additional columns and exposed information in the Folder Compare is something on our wishlist. I'll add this example case to our notes on the subject.

3) Could we get a screenshot of this? My guess is that the tolerance is set to a high enough value that all changes are considered Unimportant and that "Ignore Unimportant" differences is enabled in the toolbar?

4) Tolerance mode has a tolerances value applied to 'how different' can the pixel be. If it is within the value, it is a blue/unimportant difference. If it is outside the range, it is a red Important difference. Greyscale is used to represent the equal pixels. The blue pixels can be hidden using Ignore Unimportant Differences. If the picture is only Unimportant, then toggling this on will treat the picture as if it were equal in the Folder Compare (which also has the Ignore Unimportant Differences toggle in the toolbar). Does this help explain our current behavior? If you are still having any trouble, or seeing something different, please include that screenshot from #3. You can email us at [email protected] with a link back to this forum thread (for our reference) for private communication.

[pbrown]

I'll email you repro cases for the issues I describe (3) and (4).

Regarding (3), it doesn't have anything to do with unimportant differences. I have them disabled, and I still get this result with a tolerance of zero.

Regarding (4), the primary issue I have with the feature is that I find the greyscale for "equal pixels" kind of distracting. "Equal" looks to be displayed as ~50% grey in dark portions of the image and approximately white in brighter portions. I guess what I would really want out of "tolerance" mode would be:

- Black or some constant color (50% grey is fine) for equal pixels, without different shades based on original image brightness.

- Red/blue for non-equal pixels above and below the tolerance. Different shades are fine, though shading based on the delta rather than the original pixel color would be best.

I do realize the mode I'm describing is very similar to "Mismatch Range Mode", other than the presence/absence of the threshold. :-)

The behavior of the coloring of the gray "equal" pixels seems to depend on whether the ImageMagick conversion filter is enabled.