16-bit RGB Formats (555, 565) - Copy and Resize

16-bit RGB Formats (555, 565) - Copy and Resize

Hi,
I'm attempting to add required 16-bit RGB support to some high-speed video drawing routines...

Please could you let me know the best way to implement both "Copy" and "Resize" for both of the following RGB formats:
- RGB 555
- RGB 565

I have attempted to use ippiResize_16u_C3R but this appears to work incorrectly, is this correct function to use?

I also noted that when using version 4.1 ippiResize function is 5 times slower than ippiCopy for a 1:1 copy is this expected?

Thanks for your help,
Kind Regards,

Message Edited by dean.taylor@coull.biz on 11-01-2005 06:01 AM

8 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi,

regarding RGB555/565 formats we have only color-conversion functions, but we have not ippiCopy or ippiResize for such format of data

Regards,
Vladimir

Thanks for your prompt and clear responce,

I have been trying to work this out, some of the documentation within "ippiman" is a bit mis-leading (perhaps just to me)...

---- snip ---- (ippiman.pdf, Page 63)
For example, in an absolute color 24-bit RGB image, three consecutive bytes (24 bits) per pixel represent the three channel intensities in pixel mode. This data type is identified in function names as 8u_C3 descriptor, where 8u represents 8-bit unsigned data for each channel and C3 represents three channels.

For another example, in an absolute color 16-bit packed RGB image, two consecutive bytes (16 bits) per pixel represent the three channel intensities in pixel mode. This data type is identified in
function names as 16u_C3 descriptor, where 16u represents 16-bit unsigned data (not a bit depth) for all packed channels together and C3 stands for three channels.
---- snip ----

This seems to indicate to be that if I want to manipulate RGB 16 bits per pixel image I should be looking for functions that have a 16u_C3 descriptor!

Please could you carify for me, the exact mean this? ...
it is never good to be confused about how exactly a function works.

Thanks again,
Dean.

Hi,

you are right, it looks a bit mis-leading,as I said before,we do not have full set of functions which works with packed RGB formats (like 555 or 565). I mean there is no ippiAdd, ippiCopy, ippiResize, ...functions which work with data in such format. Instead of that we have some color-conversion functions, which can convert 8:8:8 YUV data to 555/565 RGB and vice versa.

Regards,
Vladimir

For the purposes of clarity...

if these 16-bit image functions where to exist what would the names/descriptor be for these functions?

Would they be explictly named like the color conversion functions?

Is the ippiResize_16u_C3R intended for use with YUV formats?

Thanks again,
Dean.

Dean,

please take a look on IPPI manual, chapter 6, Image Color Conversion, article RGB image formats. For packed formats there is special modificator in the function name (RGB555, RGB565 and so on).

It is clear that for resize operation meaning of color channels is not matter, it can be YUV, XYZ or RGB. What is important - sampling. Our resize functions work only with not down-sampled images.

Regards,
Vladimir

Thanks for all the info...

Do you have any views on the following?

What would the likelihood be of 16-bit (555, 565) Resize functionality implemented (Intel optimised) and added to IPP?

Has there been any other requests for this in the past?

Just interested...

Thanks again,
Dean.

Hi Dean,

yes, we had such request (something about several years ago). Actually we do not consider wide support for packed RGB formats as high priority task, you see, the world trend is to work with true-color images. In any case, if you think it would be useful functionality, please submit your feature request to Intel Premier Support channel. We periodically do review of feature requests and trying to align with our plans.

Regards,
Vladimir

Leave a Comment

Please sign in to add a comment. Not a member? Join today