In my opinion Reggae should use one, or at most two YUV formats. Remember, more "common formats" means more work for filter implementors. Other YUV subformats should be supported with conversions.
In similar frameworks, the color format is negotiated and most encoders/decoders would not support more than one or two color formats as needed by the type they (de)compress unless the author just wanted to do so.
MPEG would have YV12 and UYVY and JPEG should really have a YUV format or two added.
Having a single, optimized color conversion filter do the color conversion is better IMHO than having each and every codec add the functionality.
Filters along the chain could be upgraded to support a small number of additional formats as it makes sense. For example, UYVY can easily substitute for YV12 and BGRA can substitute for any 8bit RGB both losslessly with only a small performance hit.
It may not always be optimal, but it does function. How often it is optimal can be easily upgraded by individual filter authors.
Rzookol has plans to release source of some of his classes. I may add to this, that I work on LibMaker application, which is a GUI driven, parametrized code skeleton generator for shared libraries, BOOPSI classes, MUI classes and Reggae classes as well.
That's great to hear. I'm sure that with more examples and documentation more classes will be written.
For such formats demuxer decodes (and detaches) the header, extracts metadata (if any). Demuxers are also responsible for format recognition (Reggae performs content based recognition).
MMT_DOCUMENT is a postsign standing on a boundary of uncharted land ;-). In my opinion PSD (I guess you mean Photoshop format) is out of Reggae scope. Of course one can imagine a document, where multiple images are stacked one on another and alphablended. However PSD allows for much more than that. Layers can be combined in numerous, non-trivial ways. Do we really want the whole Photoshop compatible image composition engine in Reggae? Or it just should deliver layer images, their offsets and scaling factors and enumerate combiners used?
It seems out of scope at this point, but I like the idea of using Reggae as vastly upgraded Datatypes. They always seemed underutilized on Amiga, but perhaps I'm reading too much into what Reggae was intended to be.
How I envisioned it is fairly complicated. It would be both MMT_DOCUMENT and MMT_PICTURE as the application is able to handle.
For now I just need to focus on what is within the current scope of Reggae.