2008.05.24 03:05 "Re: [Tiff] Unitialized Variable Caused a Problem in TIFFCP", by Gene Amtower

On Fri, 2008-05-23 at 20:15 -0500, Bob Friesenhahn wrote:

There is about 3 years of difference. But both of them are old now. Needless to say, fixes appear in subsequent releases, so it is best to see if the problem still exists in 3.9.0beta and 4.0.0beta1 so that it can be fixed before the next release.

What does 'tiffinfo' report for the problem files? Are you able to provide one of the problem files as a test case?

Bob,

I can't share any of the files because they're customer material, but here's a copy of the tiffinfo output from one of them...

TIFF Directory at offset 0x2267c
    Subfile Type: (0 = 0x0)
    Image Width: 6904 Image Length: 4888
    Resolution: 200, 200 pixels/inch
    Compression Scheme: CCITT Group 4
    Photometric Interpretation: min-is-white
    FillOrder: msb-to-lsb
    Make: "Alpharel Incorporated"
    Model: "optirastoras"
    Orientation: row 0 top, col 0 lhs
    Rows/Strip: 4888
    Planar Configuration: single image plane

  Software: optirastoras: 1.6.5(beta), 2

I can tell you that these are engineering drawing images, some from scans of original paper documents some years back. Since these are monochrome prints, a fax-type format seems logical, but the program that creates them might be a bit old and incomplete in it's handling of tiff tags. I don't have access to that program; I'm just working with this material downstream in the business process, so I'm forced to work with what I'm getting out of it.

Of course, 'tiffcp' is working fine for me with my modified copy, once I initialized the "samples/pixel" variable to "1" just before trying to load the image tag for it, and as you can see from the tiffinfo output, these images seem to be missing the samples/pixel tag. I don't know if that's typical, and that's really my question to the list. As TIFF users, does anyone else see this situation--images that don't have a samples/pixel tag? I think it only causes a problem with the transform functions like "bias", as I was able to perform merges of these files from individual tiffs into a multi-page tiff without any modification.

For my purposes, I'm focused on making the watermark functionality. I've got a first cut that allows me to offset the watermark anywhere on the source images, from the upper-left corner, using two new "-x" and "- y" parameters to indicate the offset values. I also created a new watermark option "-m" followed by the watermark file spec. This is working great, and I'm now working on how to push it to the middle of each image and then offset it in any direction from there, using an additional option parameter for centering. "-c" is already used...

    (:

so I gotta come up with something else, or I could try to include it with the offset values with a "," separator. I'm still working on my options. I could include a scaling feature, but that's really more than my current needs. Of course, I would be happy to share my improvements with the world, but this could be my first hack at contributing to the open-source community.

You mentioned that 3.8.2 is old? That doesn't seem too far from 3.9.0, so has the package been dormant for a little while, or just in an enhancement-bake mode of operation? I guess I should go download the 3.9.0beta code just to see what's different.

Thanks for your interest, and I'll be anxious to share what I'm doing with the libtiff code.

Gene