Becoming an IM Contributor/Developer

[grafman]

Read through this forum and didn't see any postings on this topic; apologies, if I missed it

I'm the primary owner of CPAN's OpenGL module, and just added a new API to PerlMagick to provide tight Perl integration between IM and OpenGL. Currently running tests, and will post diffs shortly.

I believe there's a lot of potential synergy between ImageMagick and OpenGL, and would like to be contributor to both PerlMagick and the ImageMagick core.

Is there a process for becoming an IM developer with SVN write access, or are contributions limited to submitting diffs?

Thanks!

[magick]

Your first few contributions to ImageMagick should be with patch files. If your patches show promise we will give you write access to SVN. In the mean-time if you want direct access to the developers, post a private message (PM) to Mr. Magick and we will provide you with a direct e-mail address.

[grafman]

Thanks, sounds good, and will do!

[grafman]

I tried emailing my patch for new PerlMagick APIs to the mailing list provided, but got bounced... it indicated that an IP address (207.115.20.53 - not mine) was listed in spam.dnsbl.sorbs.net

So in the mean time, you can find my patch at:
http://graphcomp.com/opengl/ImageToPointer.tar.gz

Here's the rest of the message that was bounced:
____________________________________________________________
> You can use this address to communicate directly with the
> ImageMagick developers.
> Cristy

Thanks!

Attached is my PerlMagick patch. I notice that the trunk is in flux, so
hopefully the patch is still current.


I've completed my testing/benchmarks for my new PerlMagick APIs:

Get('Quantum') - returns IM's cache depth.
ImageToPointer() - returns a C pointer to IM's image cache.
SyncPointer() - syncs IM's image cache.

I decided not to add a PointerToImage API - as much as I'd like to share a
pointer between the GPU and IM, there are cases where OpenGL can release a
pointer, which would cause a seg-fault in IM. I may revisit this again in
the future.

That said, just adding the ImageToPointer API has provided a 188X
performance improvement over ImageToBlob:

ImageToBlob + glTexImage2D_s: 44.789 FPS
GetPixels + glTexImage2D_p: 45.595 FPS
ImageToPointer + glTexImage2D_c: 8614.444 FPS

ImageToBlob returns a pointer to IM's image cache - without copying.
Granted, this will only work for small or memory-mapped caches - but this is
generally the case for OpenGL textures. POGL's "_c" APIs take C pointers
directly (without copying/casting/converting) - so they'll give you nearly
the same performance as C APIs.

Since the cache size depends on IM's quantum-depth, I've added a 'Quantum'
parameter to Get. I've also added a SyncPointer to sync the cache after
it's been updated via OpenGL.

Developer's note: IM's cache is stored in BGRA format, with the alpha
channel inverted. OpenGL supports BGRA, RGBA8 and RGBA16; some newer GPUs
support RGB32F (float), but not RGBA32 (long), so this interface will most
likely be used with Q8, Q16 and possibly High Dynamic Range. Until OpenGL
adds an RGBA32, Q32 will work for VBOs, but not textures.


As indicated, I've attached a diff/patch file of my changes. Let me know
what beta version this will be tagged with, so that POGL apps can detect
whether or not ImageToPointer support is available.

Input/feedback appreciated! - Bob