This is a question and a rant about my frustrations with an API description. First take a look at this usage information for a library I have been playing with:


Now my first question: Is it clear as to you what the formats are for the InBuf and OutBuf parameters are?

Now, read his response to people (including me) struggling with determining the format of the buffers for this resize function:

Does the guy come across as condescending as hell? Am I reading into this? It is like the guy takes every opportunity to find fault with people not understanding the details he didn't put in his API description. I would find it difficult to have to work with someone like this.

The irony about this is the description of his code makes me think it is going to magically create this wonderfully rescaled image preserving details. The result is that a standard bilinear filtering scaling function looks practically the same. I saw no real perceptible improvements of his code over the scaler I tested against. When I adjusted parameters using presets he provided it didn't improve the results and added artifacts I could not accept. His scaler is also at least a magnitude slower than the bilinear version. So the code is pretty much a non-starter for my current project.

Ah well, I appreciate him posting the code and making it a very permissive license. That part is really cool.

  • 5
    I'd just downvote his shit and move onto another library.

    But goddamn I am loving these comments. That passive aggressive shit takes me back.

    Thanks for posting this.
  • 1
    Btw, the general buffer config would be x*y*d where x and y form a matrix, and d is the layer count (number of blended matrices, ex: RGB(3), RGBA(4). The unit is determined by the color depth present in the image.

    I don't expect people to know that, though.
  • 2
    Maintainer sounds like a dick
  • 3
    @SortOfTested When I first got confused I went to the code. I found in the code that InBuf and OutBuf are templated. One of the first lines in the function checked for stuff being zero on some of the dimension parameters. Then he used memset to write to the output buff using width*height*sizeof(outbuf). The problem is if the outbuf is a uchar* then it will only clear 1/3 of the outbuf. This caused me confusion as to what the inbuf and outbuf types should be. He should have used the parameter for the number of elements multiplied by the value to get the real size of the outbuf.

    I do like the template approach though. That allows the elements to not assume a uchar size and can even be floats or doubles. Kind of future proofing his code that way.
  • 3
    "AVIR is devoted to women. Your digital photos can look good at any size!"

    I couldn't help but laugh at this, from his readme.

    Anyway. We all understand that libraries in general require some sort of prior knowledge. If you suspect someone not possessing it, just kindly point them in the right direction. He has a superiority complex about image formats and uses your question to wave his image format penis in everyone's faces.

    Just based on that I'd stay away from his library. No good can come from attempting to collaborate with him.
  • 2
    I'm just wondering why he doesn't have unit tests. That's my first stop for usage examples.
  • 1
    He’s not only from Russia (I guessed it just by reading the rant), he’s from my hometown!
  • 0
    @uyouthe I thought he might be some college professor somewhere. Lol, that you might know him.
  • 0
    I checked for other image reduction libraries. To my surprise it looks like ImageMagick++ might be a good codebase to play with. The license is really permissive and the code seems to be divided up into functions. The resize functions are all in one header for instance. It has like 10 different resize algos to play with as well. Knowing ImageMagick I bet it is fast too.
  • 1
    @Demolishun funny.

    I'd recommended exactly that.

    ImageMagick or GraphicsMagick (fork from ImageMagick a long time ago) are both the swiss army knife of anything graphic / postscript / bullshit bingo format happening.

    Gd is the smallest library I know that can handle graphics.

  • 1
    "Yes, "Ultra" produces ringing/outline. If you do not see a difference between AVIR and bilinear filtering, I can't help or argue. Working with images requires quite a bit of experience to understand the differences and seeing the bigger picture."

    Holy fucking frigging shit....

    What a lil narcisstic bitch.

    Sure, if it's not working as intended everyone else is just too dumb to get it.

    I'm really astonished how some people can comment like that.

    But I'd guess they're not seeing the bigger picture...
  • 1
    1. not clear, i just assumed one or two dimensional array of mentioned supported types, and the order of channels i assumed doesn't matter.
  • 1
    and yes, the guy is extremely condescending, but if i had the same knowledge as him, and had the same indian guy asking the same question, i would most likely respond the same.

    i didn't realize each channel needs a separate field in the array, but then again, i don't know much about basics of image manipulation on this low level, and it was still obvious to me the asker ia doing something trivially stupid, and as soon as the third guy gave an example, i was like "oh, of course, channels as separate fields in the array, makes sense"
  • 1
    to be clear, the avir guy was needlessly condescending, and arrogant, and no, this is not how you provide normal, helpful support, i'm just saying that i think i understand him very well because i tend to be an asshole in the same way, when i think someone is missing a very basic piece of info that they should have learned in some "101" tutorial about the overall topic =D
  • 0
    @Midnight-shcode I just realized a way to use his library faster. Not sure what the results will be. But if I change my InBuf and OutBuf to be a single integer 32 bits wide (all 4 bytes ARGB) and set the number of channels to 1 it should work 4 times faster instead of manipulating each byte. I will see if the results are the same or better this evening. My data is already 32 bits aligned so this should be doable.
  • 0
    @Demolishun yeah, well that's why i didn't realize the "one array cell per channel" thing - i assumed from how he listed out all supported types that each of them is "one value per pixel", having all the channels packed in.

    you're welcome for the hint =D
Add Comment