ippiRGB565ToRGB_16u8u_C3R() exists, what about ippiRGB555ToRGB_16u8u_C3R?

[ILevi1]

Why there is no ippiRGB555ToRGB_16u8u_C3R()?

Even better, why there is no ippiRGBMaskToRGB_16u8u_C3R() where you could specify R, G, and B channel masks (as Ipp16u values) for extraction?

Regards,
Igor

[ILevi1]

Should I submit this as a feature request?

[rod_ma1]

We need ippiRGB555ToRGB_16u8u_C3R too,

[Vladimir_Dudnik]

Thanks for informing us. We will consider that request at next version planning stage.

Regards,
Vladimir

[Gaiger_Chen]

We need ippiRGB565ToRGB_16u8u_C3R() too, this format is very common in cell phone domain..

[ILevi1]

Umm... read the title of the thread again, it says "ippiRGB565ToRGB_16u8u_C3R() exists".

[Vladimir_Dudnik]

Right, we do have 565 variant of this function but do not have 555 variant. That we consider for future release (depend on how big demand is for that functionality,how manyother requests we do have and how they got prioritized).

Please see ippcc.h for declaration
IPPAPI(IppStatus, ippiRGB565ToRGB_16u8u_C3R,(const Ipp16u* pSrc, int srcStep, Ipp8u* pDst, int dstStep, IppiSize roiSize ))

Regards,
Vladimir

[ILevi1]

Vladimir, you sound as if it is very complex to add that function when the only difference between it and the existing function (565) is different extraction mask and shift values used. I really don't understand why it is taking so long to even consider adding something so simple, let alone implement it.

[Vladimir_Dudnik]

that is not about technical complexity of this particular request. You might not seeall other requests we have,some of themare simple enough, but there is product strategy,planning and prioritization in order to cover most important functionality.

Vladimir

[ILevi1]

With all due respect, if there was planning involved, this function (RGB555) would not have been omitted in the first place

/rant on

Planning an API involves thinking about orthogonality. But we've already seen how Intel engineers struggle with orthogonality -- x86 instruction set is another shining example of the lack of orthogonality and abundance of redundancy.

/rant off

[Vladimir_Dudnik]

With all due respect planning is not limited by thinking on ortohonality. There are many other factors which contributeat planning stage.

Vladimir

[ILevi1]

I know it is not limited, that is why I said "involves thinking about orthogonality".

[Gaiger_Chen]

Oh, It is my typo, I means "ippiRGB555ToRGB_16u8u_C3R"

currently, I convert ippiRGB555 to YCbCr420

Then YCbCr420 to RGB.

It cost additional time.