You could try reading the raw bytes of the JPEG and actually extracting the thumbnail if it's embedded (depending on what you're doing that could actually be a huge performance boost if all you need is the thumb). I think Kevin Hoyt had some code that extracted the thumbnail from EXIF data, check this stuff: http://blog.kevinhoyt.org/2007/12/18/samples-updated-for-air-beta-3/
Doug On Tue, Sep 16, 2008 at 7:56 PM, Paul Hastings <[EMAIL PROTECTED]>wrote: > Alex Harui wrote: > > Can you repro yourself? Use some tool to generate a 150DPI image and > > see if Flex can show it. Then add thumbnails, etc until it dies? > > sort of. we thought we had id-ed 3 things different from the other working > images: > > - 150 DPI > - ICC Profile > - embedded thumbnails > > a kind soul w/photoshop expertise stripped out the ICC Profile (and double > checked that these images were indeed 8 bits/channel) as well as reducing > the > DPI to 72 (not exactly sure about that as the EXIF data still says 150DPI > but > the image's properties says 72DPI). didn't help. > > we used cfimage to convert to PNG then back again to JPEG which looked > liked it > croaked the thumbnail (not 100% sure) & reduced the DPI to 96. flex still > hung > when we loaded the roundtripped JPEG images. tried the same thing > w/fireworks, > no joy. > > converting to PNG seems to be the only way to display these images. > > created a 150DPI PEG image in fireworks & it too killed flex (can't tell if > it > also embedded a thumbnail). ditto for a 96 DPI image. based on this maybe > it's > an embedded thumbnail (if fireworks does indeed embed them) as the DPI > seemed to > have no effect. though we thought the JPEG-->PNG-->JPEG round trip > w/cfimage > should have lost those??? > > btw the client is using a 3.0 SDK compiled version while we're running 3.1, > no > difference. both are running 9.x flash players. > > thanks. > > >
