Since it seems that Apple has decided that making QuickTime (DLL/API/Codecs) Windows 64-bit compatible is a thing only for the distant future, I need alternative libs for PNG and PICT image file support in my C++ plugin versions that run in Windows XP Pro x64 and Vista 64-bit. The application for the API uses QuickTime to support reading these image file formats so it is broken in Windows 64-bit versions of the application. There are some caveats here: Exception handling is a bad thing - the plugin SDK, although C++, does not use or support exceptions. It may work - it may cause crashes. If I can avoid exception handling all the better. I say this realizing that libpng requires exception handling enabled for the lib project. zlib is already available as a lib for my plugin. I've read that libpng builds zlib for itself. Should I just redirect to my current zlib.lib or would that be catastrophic? paintlib is one option here as it supports PICT but it does use libpng for PNG support - again with the exception handling. Yeah, I can try it and see how stable it is but just realize that this is for thumbnail support and will be called many times - any instability will be swift and fatal. This goes to show that even the big guys (SoftImage, Maxon, AutoDesk, ...) place their dependencies on iffy third-party support. By not updating QuickTime, they are hurting them and everyone dependent upon them (plugin developers). I would never entrust my support of features to Apple... Thanks, Robert

Quote:Original post by Yann L
What do you mean by requires exception handling ? libpng is a 100% C library, it doesn't even know what an exception is. It (optionally) uses setjmp however, which basically is a glorified goto. While abominable, it can be easily wrapped in a reader/writer class, without ever affecting anything else in the code.

Maybe I'm confusing libpng with paintlib. paintlib definitely requires exception handling. Since it supports PICT, it is the best course (and only from what I've not found online). I don't know of any other C/C++ lib that supports PICT file reading.

Quote:libpng by itself doesn't build zlib, only the supplied makefiles (optionally) do. You can build libpng without rebuilding zlib, and simply link to a static or dynamic version of zlib you happen to have lying around somewhere.

That's good. I may try with the zlib (1.2.3) build and see if there are any complaints in the main plugin project having one version of zlib for paintlib and another for the other stuff. Since these should remain isolated it may work - or may conflict. Any thoughts there?

Quote:Well, libpng is a very good library. A lot of commercial software packages use it with success.

Yep. I'm only driven to use it by Apple's lack of foresight though. What will they do when there are a hundred million users with Windows Vista 64-bit? (My thought - cave-in or lose a ton of business).

Thanks,
Robert

Quote:Original post by Yann L
PICT, being primarily an Mac format, is rarely used on PC. It seems to support vector based images, so reading it is not trivial, and will most likely require a bytecode interpreter of some sort. Maybe you should look into the specification of the format. If the code syntax is similar to postscript or PDF, then you could adapt an existing interpreter, or write your own.

I wish more rarely. ;) The plugin involves use of Poser libraries which mainly use PNG and RSR (a file on Windows and Resource data on Mac) for thumbnail images of the content. The RSR always embeds a PICT image as a resource here. Unfortunately, there has been some back and forth - Poser itself now uses PNG (and replaces RSRs with them), but some content providers have decided that RSR is better (one is the biggest provider). If you have Poser installed and visit the library content in the Library browser then PNG files are automatically created. But that doesn't suit me as there are users with earlier versions of Poser that don't do that, no Poser (maybe DAZ|Studio), or don't open Poser and get the necessary RSR->PNG conversions.

Quote:Out of curiosity, what application are you working with ? If the SDK gets unstable by the simple fact of enabling exceptions, then this is a very bad sign - a sign of very bad design and programming from the side of the host app. Do you have access to its source ?

Maxon Cinema 4D. Most of the exception handling instability is exhibited on MacOS X (Universal Binary - Xcode). To my knowledge, it has not caused any problems on the Windows or Mac PPC (CodeWarrior) builds - so this could be a good thing as this fix is explicitly for Windows 64-bit. Only one of the third-party libs utilized it and it was a simple process to change the exceptions into error returns to resolve the instability. paintlib, on the other hand, would be a major task to convert as it is a very much larger library and uses exceptions frequently. Don't really want to mess with it to that extent.

The API is pretty clean but their lack of exception handling criteria is upsetting for someone from a Java background. Though it must be admitted that I'm pushing the API pretty hard as well - there are already a dozen or more plugins in this plugin suite and two third-party libs. Now there'll be a few more (paintlib, libpng, and libjpeg (for JPEG-encoded PICTs)).

Quote:As long as you link to static zlibs from different modules (ie. libs), there should be no conflict. It will obviously use more memory though. Linking to different dynamic versions zlib is a no-go, as you can imagine.

Good. Yes, this will be a static lib not a dynamic one for sure. Size doesn't matter (well, in this case anyway). Shouldn't increase much - what's a 100KB on a plugin that is 1.5MB already.

Thanks much,
Robert

Quote:Original post by Kuroyume0161
I don't know of any other C/C++ lib that supports PICT file reading.

ImageMagick can read and write PICT images, as well as a a whole lot of other formats.

GraphicsMagick — a fork of ImageMagick — can handle that format as well.

Quote:Original post by let_bound
ImageMagick can read and write PICT images, as well as a a whole lot of other formats.

GraphicsMagick — a fork of ImageMagick — can handle that format as well.

But ImageMagick is an *application* unto itself and requires an install *and* configuration, even to use the MagicWand API interface (if I misread this, please provide a link) - seems about the same for GraphicsMagick. In essence, these are applications with API interfaces for use in other apps. I will not play 'tech support' for either if users don't install it or misconfigure it (etc.) - many of my users are not native English speakers and I have enough trouble doing my own tech support. ;)

Also similar to QuickTime in this respect. I really don't want to tie to anything external that could be missing or change over time - no matter how well supported. This is why I fought hard to build my own zlib lib in Xcode as too many users were having difficulties with the use of 'expected' libz.dylibs either unfound or varying in version. This comes *with* the MacOS X system and they still can't nail down a version, a location, proper support for a variety of possible code configurations. My build works no matter what.

Thanks,
Robert

Quote:Original post by phil_t
Well, for PNG you could use the windowscodecs stuff:
http://msdn2.microsoft.com/en-us/library/ms736014.aspx

Although it looks like it requires .NET 3.0 to be installed on XP:
"Windows XP Service Pack 2 (SP2) with Microsoft .Net 3.0, Windows Vista"

Hmmm. I have Visual Studio 2005 Pro for building for the 64-bit environment. .Net 3.0 could be a concern if it is a required component install for the users to get the functionality. As long as it is something available for Vista and x64 as a component install that wouldn't be a big problem.

But would this work under Windows XP Pro x64 and Vista 64-bit as it says 'Win32' rather explicitly? This is for a 64-bit application running on Windows 64-bit.

I don't 'do' Windows API programming - avoid it like the plague (same for MacOS - but I've had to do some to get at Resource data for this particular plugin). That's why I went from C to Java. C++ for the plugin SDK was non-optional. :)

Actually, I should be saying 'plugins'. There are Ltd and Pro versions, two separate products which have similar issues with PNG-PICT.

Thanks,
Robert