Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: Where are the weak points?  (Read 7708 times)

0 Members and 1 Guest are viewing this topic.

Offline Heiroglyph

Re: Where are the weak points?
« Reply #30 on: September 29, 2014, 03:43:15 PM »
Quote from: Krashan;774156
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.

Quote

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.

Quote

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.
 

Offline krashan

Re: Where are the weak points?
« Reply #31 on: September 29, 2014, 04:27:57 PM »
Quote from: Heiroglyph;774171
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.
Reggae features format negotiation as well. For example when we talk about RGB color formats, the only format which must be handled by filters, is ARGB32. However decoder can deliver (and encoder can request) any of {RGB24, ARGB32, BGR24, BGRA32, ABGR32}, decoder can also deliver LUT8 with palette. Reggae automatically inserts converter into the pipeline. Converter object is of either videopcm.decoder or videopcm.encoder class. They feature highly optimized conversions, including routines accelerated with AltiVec engine. Similar mechanism is implemented for audio formats. Additional formats may be added if needed.

A function in Reggae connecting two objects is tag based, so in the future format negotiation may be controlled by application.
 

Offline rzookol

Re: Where are the weak points?
« Reply #32 on: October 07, 2014, 06:58:54 PM »
For anybody interested:
http://brain.umcs.lublin.pl/~rzookol/download/reggae_example.lha
The archive contains iff deep decoder demuxer class sources
Please contact me if you have any question or you are going to write any decoder.
 

Offline Heiroglyph

Re: Where are the weak points?
« Reply #33 on: October 07, 2014, 07:36:13 PM »
Quote from: rzookol;774618
For anybody interested:
http://brain.umcs.lublin.pl/~rzookol/download/reggae_example.lha
The archive contains iff deep decoder demuxer class sources
Please contact me if you have any question or you are going to write any decoder.


Thanks, this is a great example!
 

Offline Thorham

Re: Where are the weak points?
« Reply #34 on: October 07, 2014, 07:41:52 PM »
Quote from: Heiroglyph;774171
JPEG should really have a YUV format or two added
You can't add YUV to JPEG, because YUV is an analog format. JPEG uses YCbCr.
 

Offline Heiroglyph

Re: Where are the weak points?
« Reply #35 on: October 07, 2014, 08:08:08 PM »
Quote from: Thorham;774621
You can't add YUV to JPEG, because YUV is an analog format. JPEG uses YCbCr.


You are technically correct, the best kind of correct!

The differences are very subtle though and unless you also flag for bt.709, bt.601, etc, you still won't know how to interpret it accurately.

If we get any one of the above, at least video would be feasible.
 

Offline rzookol

Re: Where are the weak points?
« Reply #36 on: October 07, 2014, 08:47:40 PM »
Quote from: Heiroglyph;774622
You are technically correct, the best kind of correct!

The differences are very subtle though and unless you also flag for bt.709, bt.601, etc, you still won't know how to interpret it accurately.

If we get any one of the above, at least video would be feasible.



Decoders still can output ARGB32 video, in fact this format is required for decoder output. Other common format can be selected using MMA_UseBestFormat  tag. In this mode, decoder try to decode image with nearest common format available. For example, for 8bit jpeg data it outputs normally ARGB32 but with this tag, user can ask decoder about output format for given image and process it directly as gray8.