[QT] Crossplatform scaling of GWorlds - Programmer

This is a discussion on [QT] Crossplatform scaling of GWorlds - Programmer ; I'm currently working on a project that involves reading image files and generating scaled down JPEGs as previews. This code is eventually destined to be run from a file server that provides asset management services. Most of the time, I ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: [QT] Crossplatform scaling of GWorlds

  1. [QT] Crossplatform scaling of GWorlds

    I'm currently working on a project that involves reading
    image files and generating scaled down JPEGs as previews.
    This code is eventually destined to be run from a file server
    that provides asset management services. Most of the time, I
    can use QuickTime's graphic importers to deal with many of the
    formats the project is supposed to support.

    Recently, I have had to add support for a file format that
    QuickTime doesn't understand; a format that uses an "interlaced
    planar" pixel map. What I'm doing with such a file is manually
    loading in the file's image data into a memory block and then
    skimming through it, deinterlacing every 3 or 4 rows into one
    "chunked" row. Once done, I can then wrap a GWorld around
    it using QTNewGWorldFromPtr and pass it as an input into
    a graphic exporter. This works just fine.

    However, the resulting image is the same size as the original and
    I want to make a version that's smaller, based on sizing
    parameters being passed from other calling code. What I tried
    to do at first was creating a second GWorld with the target
    image's file dimensions and then using CopyBits to scale it down.
    This doesn't work; on the Mac, certain pixel map formats like CMYK
    lose color information. And on Windows, the QuickTime version
    of CopyBits doesn't appear to support scaling consistently.

    What I've been forced to resort to is creating a temporary scratch
    file. I read in the original file's image data into memory,
    de-interlace it, save it back out at full size using a non-
    compressing exporter (kQTFileTypeQuickTimeImage, in this case),
    then reopen the file using a graphics importer. Once I have this
    importer, I can call GraphicsImportSetBoundsRect to scale the
    image when it is hooked up to a JPEG exporter.

    What bothers me about this is the time it takes to complete the
    process. I'm essentially loading the file and saving it twice.
    On my work iMac, it takes about 15 seconds to process a 25 meg
    source image. On a server grade testing PC, it still takes 3
    seconds. Photoshop files, which are also planar (just not
    interlaced), only take a third as long. While I can expect some
    extra processing time for deinterlacing, this is way too much.
    I also don't like dumping an additional file that is as big as
    the original image on the hard drive, even if it's just temporary.
    (I'm already chewing up system memory to load the entire file,
    but that's fast and ephemerial so I can deal with that.)

    I want to know if either of the following is possible:

    - Can one create a graphics importer that works on a GWorld instead
    of a file? It appears to be possible to point to a memory block
    using GetGraphicsImporterForDataRef, but it assumes that an entire
    file is read in instead of just the image data. (I.E. it expects
    header and metadata info)

    - Can CopyBits or a similar call work on the both Macs and PCs for
    pixel maps of the formats non-alpha 8-bit RGB, 8-bit greyscale and
    8-bit CMYK? These are the three formats the file type contains
    once de-interlacing is done. That last one is key, the GWorld
    format supports subtractive color via the 'cmyk' pixel format, but
    using CopyBits on them leads to dropping color information.

    Des

    --
    Des "Wormwood" Courtney | 1 Little, 2 Little, 3 Little Endian
    | 3 Big, 2 Big, 1 Big Endian

  2. Re: [QT] Crossplatform scaling of GWorlds

    In article ,
    Des Courtney wrote:

    > - Can one create a graphics importer that works on a GWorld instead
    > of a file? It appears to be possible to point to a memory block
    > using GetGraphicsImporterForDataRef, but it assumes that an entire
    > file is read in instead of just the image data. (I.E. it expects
    > header and metadata info)


    You can make an importer that works on any format of RAM-based data you
    wish, provided you can provide via some other mechanism (image
    description extensions would be the logical way) enough information for
    your importer to know how to process the data.

    > - Can CopyBits or a similar call work on the both Macs and PCs for
    > pixel maps of the formats non-alpha 8-bit RGB, 8-bit greyscale and
    > 8-bit CMYK? These are the three formats the file type contains
    > once de-interlacing is done. That last one is key, the GWorld
    > format supports subtractive color via the 'cmyk' pixel format, but
    > using CopyBits on them leads to dropping color information.


    CopyBits() doesn't know anything about CMYK, so there is your problem.

    A better way to perform scaling (it is more capable and gives better
    quality) is to use a QuickTime decompression sequence
    (FDecompressImage). If you specify codecLosslessQuality you'll get
    bicubic interpolation of the pixels.

    However, if you are looking for sophisticated undercolor removal/black
    generation in a CMYK<->RGB conversion, you aren't going to see that via
    QuickTime either. Future versions of QuickTime will make use of
    ColorSync on the Macintosh to do this, but they do not currently.

+ Reply to Thread