Add "Pixel format" to status line (#208)

[mattipee]

An alternative to this which may be more useful in fact might be to substitute a string representation of pixel format for bit depth which in itself is still a little opaque:

eg state.mainWindow->setPixFormatValue( OA_PIX_FMT_STRING( format ) );

Happy to make this become that instead...

[mattipee]

I retract my pull request for bitDepth, pixelFormat is more useful.

My implementation uses a higher-order macro, sorry.

No longer specify integer values for the formats, it's automatic.

It goes like this...

#define DEFINE_OA_PIX_FMT(OA_PIX_FMT) \
  OA_PIX_FMT(RGB24) \
  OA_PIX_FMT(GREY8) \
  OA_PIX_FMT(GREY16LE) \

#define OA_PIX_FMT_GRAY8    OA_PIX_FMT_GREY8 
#define OA_PIX_FMT_GRAY16LE OA_PIX_FMT_GRAY16LE

#define ENUM(FMT) OA_PIX_FMT_##FMT,
enum { OA_PIX_FMT_NONE = 0,
       DEFINE_OA_PIX_FMT(ENUM)
       OA_PIX_FMT_MAX };

#define STRING(FMT) #FMT,
static const char *oa_pix_fmt_strings[] = {
    "error", DEFINE_OA_PIX_FMT(STRING)
};


#define OA_PIX_FMT_STRING(x) \
    oa_pix_fmt_strings[x>0 && x<OA_PIX_FMT_MAX ? x : 0]

DEFINE_OA_PIX_FMT is a higher order macro that lists the supported pixel formats, RGB24, GREY8, etc... which can get called with either ENUM or STRING.

Called with ENUM, it generates OA_PIX_FMT_RGB24, OA_PIX_FMT_GREY8, ... without indices, so we embed that in an enum { }... with OA_PIX_FMT_NONE=0 and OA_PIX_FMT_MAX entries before and after.

Called with STRING, it generates "RGB24", "GREY8", ... and that gets embedded in a string array definition.

The old #define OA_PIX_FMT_XXX N becomes an entry in an enum instead, and OA_PIX_FMT_STRING(x) does a bounds checked lookup in the string array based on N.

You lose the debug-ability of printing out a numerical format value and scanning the list of #defines, but can instead just print out OA_PIX_FMT_STRING(format) instead of format itself. I could see no numerical correspondence between OA_PIX_FMT_ and any other XX_PIX_FMT_ definitions. Also noted that 26 was missing. Also noted that inserting for example GRBG10 and GRBG10P in the middle of the list required changing all other indices, or adding them at the end, neither helpful. This way, you can add formats mid-list and it sorts itself out.

[mattipee]

All that said, I chose to do it with the lightest-touch-possible... one could define all the pixel format strings manually or even go as far as to define a structure of pixel format properties, but instead #define -> enum and a string lookup feels ok, and there's an overall advantage to eliminating the numerical indices.