One: Compiler Frontend support for YUV to RGB

[AShedko]

TF OP: https://www.tensorflow.org/api_docs/python/tf/image/yuv_to_rgb

On the topic of supporting YUV to RGB op in Luci IR:
Given that toco transforms it into reshape(S0,FC(W,reshape(S1,x))) how should we implement it?
Should we follow toco and transform it to a subgraph, or a custom operator?

[binarman]

+cc @seanshpark @parjong

[AShedko]

[seanshpark]

I think; as we support Reshape and FullyConnected, no new Op support is necessary.
1) add an TF example : yuv_to_rgb already exist; nothing to do
2) add a recipe NET_YUVtoRGB and see if it works :) if not, let's fix the bug...

[parjong]

For float model, I also agree with @seanshpark ;-)

Unfortunately, we need a quantized version of this operator ``).

[binarman]

@parjong
Should we add it as a circle-specific operator (like instance norm) in that case?

[seanshpark]

I think like FullyConnected_U8_000 model

[binarman]

@parjong
Does quantized FC + reshapes satisfies your requirements or you prefer to work with fused operator?
If you don't have strict requirements yet, we can postpone this discussion for later.

[parjong]

Should we add it as a circle-specific operator (like instance norm) in that case?

I have no idea, but I guess so.

Here is some rationale behind the above argument (that I can think of as of now).

Let's refer to the above model as M.

Given a reference float input FI, do inference with M and get the output FO.

Then, quantize the model with the following quantization parameters:

• input scale SI
• input zero point ZI
• output scale SO
• output zero point ZO

Let's refer to this quantized model as QM.

Do the inference with QM as follows:

QI = quantize FI with SI, ZI
QO = infer QM with QI
FQO = dequantize QO with SO, ZO

We can use the approach that @seanshpark suggested above if FQO and FO are _reasonably(?)_ similar, but I'm not sure whether this holds ``).

[parjong]

Does quantized FC + reshapes satisfies your requirements or you prefer to work with fused operator?
If you don't have strict requirements yet, we can postpone this discussion for later.

Frankly speaking, I have no requirement :D

The requirement comes from our customer (not me), and https://github.com/Samsung/ONE/issues/1833#issuecomment-638105806 is the only thing that I can say as of now (very very unfortunately).

---

I personally prefer to "quantized FC + reshapes" approach as it looks a bit easy to implement from my view although I'm not sure whether it is really easy to implement.

My key question is that which approach can make our customer happy ``).

[AShedko]

I think a subgraph approach is better, even TF itself does not save YUV_to_RGB as a distinct op, instead saving it the same way tflite does.

[AShedko]

All PRs are merged. Closing