I'm not sure why single-header is an advantage over powerful libraries such as GEGL.
easy to test and integrate to your project.
Show HN: PlutoFilter- A single-header, zero-allocation image filter library in C
11–18 of 18 posts
Re: Show HN: PlutoFilter- A single-header, zero-allocation image filter library in C
#12I'm not sure why single-header is an advantage over powerful libraries such as GEGL.
It's sort of like how a clean organized desk is an advantage to some but a hindrance to others....
Re: Show HN: PlutoFilter- A single-header, zero-allocation image filter library in C
#13Quite nice. Although, it seems to be making some pretty interesting assumptions. For example, most operations seem to assume ARGB inputs are premultiplied-alpha and will call PLUTOFILTER_UNPREMULTIPLY_PIXEL.
Re: Show HN: PlutoFilter- A single-header, zero-allocation image filter library in C
#14Wow
Really easy to add it into an existing project,
Written in C99...
Great job!
Re: Show HN: PlutoFilter- A single-header, zero-allocation image filter library in C
#15Congratulation! Great work! I really like his PlutoVG, LunaSVG and PlutoSVG.
Re: Show HN: PlutoFilter- A single-header, zero-allocation image filter library in C
#16nice, like Blend model
Re: Show HN: PlutoFilter- A single-header, zero-allocation image filter library in C
#17I was wondering how it would do arbitrary-sized kernels without dynamic allocation (my guess was that it would use the input/output buffer as a temporary storage). The answer is that there's a _slight_ asterix to the 'zero-allocation' - the allocation is on the stack [0], but it's small-ish (2kb) and fixed size. So in an embedded context you'd just want to make sure you have headroom for this. [0] https://github.com/…
It's interesting. On embedded, heap allocation is usually not done. If it is, it's permanent- free does nothing. Not always the case, you can enable a real alloc/free algorithm, but usually you don't need to free so it doesn't matter. The stack, though... If you take 2KB of stack and you haven't linked that much in, good luck trying to find that "bug" for why everything gets corrupted/crashes. My point here isn't that 2KB is big for embedded, it's actually that I'd prefer it just either statically allocates the memory or uses the heap so I can at least get an "out of memory" error
Re: Show HN: PlutoFilter- A single-header, zero-allocation image filter library in C
#18Well done and great with all the examples. Kind of wish I had a use case for this already, but I probably have :)