[Pfspd-users@sf.net] PV component mapping progress

[Bram R. <bra...@nx...>]

Dear all,

Clemens and I made some good progress in implementation of the generic
component mapping functionality in PV.

Developers can now have a look in the repository and experiment with the
current code. For 8 bit and 16 bit components, most functionality is
expected to work well. Some work is still in progress for other word
widths in the vector and scalar overlay handling.

We encouter a few design issues that we would like to discuss with
the community.

We reported before the following summary from the Readme.txt file:
- Component mapping is added. Users can now select which components
to use for each of the color display methods. With this functionality
files with an arbitrary number of components can now be handled well.
- A new color display method "RGB" is added. Further, as part of the
addition of the component mapping, the names of the color display
methods are updated.

The generic principle is as follows: for each of the color modes,
the user can select which component to use assording to the
following table:
color mode    component role ("use as")
YUV           Y,   U,   V
RGB           R,   G,   B
Y             Y
Y+V           Y,   Vx,  Vy
V             Vx,  Vy
Y+S           Y,   S
S             S

The color mode RGB is new compared to the latest relase.

Note 1: no RGB->Y matrix anymore
In the past, an RGB file was specifically recognised and converted
to Y in case of color mode "Y". Now, RGB mode always requires three
components. So the functionality to convert RGB to Y is lost.

Questions: is this missing functionality considered a serious loss?
If yes, what is a good approach to resolve this? An extra color mode?
Are we willing to pay the burden of yet an other color mode (burden
in the sense of increased UI complexity, ease of use, etc)?

Proposal: forget about rgb->y conversion to keep the concept simple
and streamlined.


Note 2: what to do with the location info?
In the current release, all component values are shown in location info.
This is not feasible anymore with the many components we now support.
With e.g. a 20 component file, this also means that all components must
be loaded, yielding a performance penalty.
Secondly, some components are treated in a special way: for "MVX" and "MVY"
the offset is subtraced, so binary offset representation is changed
into 2's complement. Further, the subpixel accuracy is handled
resulting in a float representation.
With generic component mapping, we cannot select on component name.
Hence an other criterium is required.
Here are the options:
Option 2A: display only the components of the current color mode
  In this case, the role of each of the components is known,
  and vx/vy components can be handled accordingly.
  Furthermore, also U and V can be converted to 2's complement
  (which is different from the current release, but a clear advantage).
Option 2B: display all components used in any of the color modes
  In this case, the plain value (binary offset) as read from
  the file is displayed, since one component can have multiple
  roles.

We propose to build option 2A.


Note 3: vector subpixel resolution
In the current release, this is hardcoded as follows: 8 bit vector
components are assumed at 1/4 pixel accuracy; 16 bits vector components
"MVX" and "MVY" are assumed at 1/16 pixel accuracy.
We propose to add a menu entry for "accuracy" (character 'a') similar
to the vector range. Default is 1/4 if both vector components are 8 bits,
otherwise 1/16. This vector accuracy is used both in the overlay and
in the location info (provided 2A is chosen).


BTW. Multiplexed components are handled fully transparantly as separate
components in the user interface.

Your thoughts are appreciated.

Kind regards, Bram.
--
Bram Riemens, Senior Principal
NXP Semiconductors / Corporate I&T / Research
Email: bra...@nx...
<--- New address and phone since June 2007 -->
Phone: +31 40 27 25910; Fax: +31 40 27 44639
High Tech Campus 32 (floor 1, office 140)
5656 AE Eindhoven, The Netherlands

The information contained in this message is confidential and may be
legally privileged. The message is intended solely for the addressee(s). If
you are not the intended recipient, you are hereby notified that any use,
dissemination, or reproduction is strictly prohibited and may be unlawful.
If you are not the intended recipient, please contact the sender by return
e-mail and destroy all copies of the original message.