#9 ASCII 0 vs 0 in RGBADescriptor

[Vladimir]

Both the AAF and the MXF specs, agree on the implementation of RGBALayout. Specifically, on page 94, the AAF Object Specification 1.1 stipulates that: "After the components have been specified, the remaining Code and Size fields should be set to 0."

However, someone probably confused the number zero with the ASCII character zero and the toolkit currently uses the ASCII character 0. Specifically the toolkit uses kAAFCompNone which is defined as hex 30, which is decimal 48, which happens to be the ASCII code for zero.

Because we do not want to break older toolkits, this patch does not address the writing of kAAFCompNone. The only changes here are to ImplAAFRGBADescriptor::CountPixelLayoutElements and ImplAAFRGBADescriptor::CountPaletteLayoutElements, in both places the code has been modified to check for BOTH kAAFCompNone (ASCII zero) and kAAFCompNull (the number 0).

While that is the only change in this patch, it is worth noting that further improvements can be done.

Currently the count traverses the pixel and palette layout arrays from 0 to MAX_NUM_RGBA_COMPS and increments the count when ever an element does not equal 0. The count does not stop once it encounters 0, it just ignores it.

This creates the possibility for the following scenario:

If an array contains [r][g][0][0][0][0][b][a] the reported count would equal 4. However, the get functions does not skip over 0 and simply returns the requested number of elements, starting with the element at index 0. So for the above array, a call to get with 4 would return [r][g][0][0].

A further improvement to the toolkit might be to stop the count once the first instance of the number 0 is encountered. It may be worth considering the same for both 0 and the ASCII character zero.

Yet another improvement might be to simply always return MAX_NUM_RGBA_COMPS and not waste any CPU cycles ignoring zeroes. Presumably the client would be able to handle that.

And yet another possible improvement might be the refactoring of ImplAAFRGBADescriptor::CountPaletteLayoutElements and ImplAAFRGBADescriptor::CountPixelLayoutElements, currently both copy the palette and pixel arrays into a local RGBComponentArray and then loop over the local copy. A refactoring would create a new function, which takes a constant RGBComponentArray and iterates over it. Then CountPaletteLayoutElements and CountPixelLayoutElements would simply call the new function with the palette and pixel arrays. This would eliminate code duplication.

[Vladimir]