Magick++ and libpng dependency

[trevor123]

Hello

I have a few questions that I'd be grateful for detailed answers to. The questions arise because, after building a variant of libpng, and rebuilding Magick++ against it, I saw no discernable differences in decode/encode times (despite having compiled libpng with the neon intrinsics enabled and running it on a neon enbaled cpu).

1) Could someone please explain to me what Magick++'s dependency on libpng is actually for?

That is, is Magick++ using libpng to encode/decode pixels/png data, or is Magick++ (png.c coder, in PNG's case) doing the encode/decode itself, and only using libpng for data structures (as opposed to processing)?

2) What is the 'delegate' and when would I use it? From reading the documentation, it appears to be an external program that can then be wrapped and loaded by ImageMagick in order to use its functionality. Why, then, would users ask whether they can use libpng? This relates, obviously, to my first question (ie can one wrap libpng and use that (libpng), instead of the decode/encode capabilities of the PNG coder directly)?

Thanks for your time

[dlemstra]

Magick++ is a C++ wrapper for the ImageMagick library and that uses libpng to encode/decode PNG files. It does not have its own encoding/decoding.

A delegate is a library that is used to perform a certain functionality. Our PNG coder uses the libpng library to encode/decode PNG files.

I have no idea why you don't see a performance difference. Are you testing this with large images?

[trevor123]

Thanks.

"A delegate is a library that is used to perform a certain functionality. Our PNG coder uses the libpng library to encode/decode PNG files."

Must I use this delegate mechanism in order to use libpng, or it that unnecessary (I only ask to ensure that I understand correctly)? Is it that Magick++ uses the system's libpng OR, if chosen, the delegate libpng (and not the system's libpng)?

The images range in size, from 800x400 up to 2048x1536, and over.

I should also add that I'm using IM6, rather than the latest.