Excellent, this means we don't need to worry with respect to the type of picture. And the code I posted earlier does show the picture in a textfield correctly, and I assume then that the current Error message with respect to the TIFF icc color will not show up in the console in release 2011. And reverting the Handle from a CGImageRef back to a REALpicture or CGImageRef is trivial and works fine as long as the REALpicture was converted to a TIFFRepresentation. Note that I am not interested in a true PicHandle with a 512 byte header, just the data as a TIFF representation, which needs to be put into a Handle, not a pointer.
Thanks for the response, seems like we are moving forward rather quickly. Alfred On Dec 20, 2010, at 6:28 PM, Joe Ranieri wrote: > I am going to assume you're talking about the RB Cocoa framework, > since I am unfamiliar with the Carbon stuff past some hand wavy "it > uses GWorlds, usually" statement. Here are how things work currently: > > A REALbasic Picture object always operates on a CGBitmapContext and > then builds a CGImageRef from there when needed. So, even if you > create a Picture by loading a .pct file from disk, we end up doing > exactly the same thing. This means that REALLockPictureDescription > will only work for pictureCGBitmapContext. > > Also, the fact that TIFFRepresentation doesn't work is most likely > related to a bug we fixed in 2011r1. What was happening is that > CGImageCreateWithMask was returning an image with an invalid data > source. > > As for getting an actual PicHandle, I don't know. One thing you could > try is converting it to some external format like a TIFF and then try > using the old QuickTime graphics importer APIs. > > Hopefully that helps some! _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
