iwiImage_Alloc fails for zero height image

[BMart1]

Bug: You can't alloc a zero size image in Integration Wrappers for ipp because ippsMalloc returns nullptr and iwiImage_Alloc thinks this is an error.

Bruno

[BMart1]

Intel, could you reproduce this bug? Should I report it elsewhere?

[Pavel_V_Intel]

Hello Bruno,

What is your usage case for such input? This function was designed to treat zero size as invalid parameter. I need justification to consider such design a bug.

[Adriaan_van_Os]

See http://pubs.opengroup.org/onlinepubs/009695399/functions/malloc.html. The standard requires that allocation of zero size is not an error. And there are many practical uses for it (e.g. not having to make this a special case in application code).

Regards,

Adriaan van Os

[BMart1]

Pavel, my use case is as Adriaan says, to not have to make a special case. malloc itself is an example of the behavior that normal C programmers will find less surprising: accept zero size. ipp deviates from this expectation when ippiSet returns ippStsSizeErr or Resize returns ippStsNoOperation

[Pavel_V_Intel]

Thanks Adriaan, thanksBruno, this is a good reason for me.

I will adjust iwiImage_Alloc function to avoid this error. I will be glad to hear other suggestions for IW API improvement if you have any. 

Bruno,

ipp deviates from this expectation when ippiSet returns ippStsSizeErr or Resize returns ippStsNoOperation

What is wrong with ippStsNoOperation? It is a fair warning and doesn't require you to do any action or even check it if you don't want to.

[BMart1]

I define a function

void Check(IppStatus result)
{
    if (result == ippStsNoErr)
        return;
    throw std::exception(ippGetStatusString(result));
}

and then call all ipp functions as

Check(ippiResizeAntialiasing_8u_C1R(...));

Treating each ipp function separately is too much work. Warnings are treated as errors, since for example ippStsAffineQuadChanged should never happen.

As for improvements to iw, I regret losing the separation of linear, cubic, etc.. interpolation modes into separate functions, reducing bin bloat. Having an interpolation parameter is more convenient, but maybe it could be a template parameter to resolve at compiletime.

I don't like that IwImage may or may not own it's memory. I think it should be split into two classes as std::string and std::string_view.

iw does some work itself that could delegate to ipp, such as computing the stride alignment instead of calling ippiMalloc.

I do like that the lib is C and linkeable with all C++ compilers, but I would hide the C interface. C programmers evidently don't care about convenience ;-(

[Pavel_V_Intel]

Treating each ipp function separately is too much work. Warnings are treated as errors, since for example ippStsAffineQuadChanged should never happen.

It seems that the problem is in different interpretation of warnings and errors. For some applications warnings can be neglected, for some they are no less than errors. I will think how to mitigate this problem.

As for improvements to iw, I regret losing the separation of linear, cubic, etc.. interpolation modes into separate functions, reducing bin bloat. Having an interpolation parameter is more convenient, but maybe it could be a template parameter to resolve at compiletime.

This was one of the tradeoffs, same logic can be applied for data types and channel types and thus C layer will be reduced back to IPP. We thought that source distribution will allow users to tailor functionality, allowing them to remove functions which they don't need. We will introduce additional defines for IW building to make it easier. 

I do like that the lib is C and linkeable with all C++ compilers, but I would hide the C interface.

I am considering to hide C interface under different namespace for C++ headers. Currently there is a mess of IPP, IW C and IW C++ names.

[BMart1]

Maybe ipp needs something like the Direct3d debug layer.