Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Oversize Tiff Files Identification 2

Status
Not open for further replies.

ricardo1023

Programmer
Mar 23, 2008
54
US
I do have hundreeds of thousands of image files that need to be printed. We have more than one printer and we need to identify which files correspond to very large blueprints (paper size is 24 x 30) In Windows explorer there is a column called "Dimensions" that may help with the identification (by dividing the numbers by 3 or something like that). Any idea how to accomplish this programatically?

Thank you
 
I do not, but someone else may. Resolution is an item in the file Summary, but I do not know how to access that. I do not know if DSO will get it. Speaking of my test file, FileProperties > Summary shows a 96 DPI, but if I bring it into a graphics app (Corel or Photoshop) it shows being 72 DPI.


Shrug.

Gerry
 
>Any idea on how to get the horizontal and the verticar resolution

Sure

Here's a more generic variant of my earlier code:
Code:
[blue]Public Function GetExtendedProperty(strFilePath As Variant, strFilename As Variant, strProperty As String) As String
    Dim lp as long

    With CreateObject("Shell.Application").Namespace(strFilePath)
        For lp = 0 To 255
            ExtendedProperty = .getdetailsof(.items, lp)
            If ExtendedProperty = strProperty Then
                GetExtendedProperty = .getdetailsof(.items.Item(strFilename), lp)
                Exit For
            End If
        Next
    End With
End Function[/blue]

Which you can then call using "Horizontal resolution" (or "Vertical resolution") as the strProperty
 
I can not get that to work.

I also do not get anything near 255 items. In fact, if I get it to write each one
Code:
With CreateObject("Shell.Application").Namespace(strFilePath)
   For lp = 0 To 255
      ExtendedProperty = .getdetailsof(.items, lp) & vbCrLf
      
      [b]Selection.TypeText Text:=ExtendedProperty[/b]
I only get 38 written items, one of which is "Horizontal resolution" (or Vertical)...and 200+ blank lines.

Further, even in Explorer I can not get a horizontal or vertical dimension to show. Although in file properties, under Summary, I can see both.

Gerry
 
I only get 38 written items, one of which is "Horizontal resolution" (or Vertical)...and 200+ blank lines.


That should be NONE of which...

Gerry
 
> also do not get anything near 255 items

Ah, different OSs add support for new properties. My example just loops through the first 255 possible columns, some (or many) of which will be empty. I had thought that I recalled that XP directly supported the "Horizontal resolution" property, but now I think about that I recall that property was only introduced to the shell in Vista ...

In XP the shell uses custom handlers to extract additional info from various file types ... hmmm ...

 
Yes, the extended properties are OS-dependent, so you may or may not see them, but the mere fact that they are so indicates that they are not inherent properties of the picture, rather values determined by the OS (and, AIUI, related to the combination of picture and output device/medium).

Enjoy,
Tony

------------------------------------------------------------------------------------
We want to help you; help us to do it by reading this: Before you ask a question.

I'm working (slowly) on my own website
 
So Tony, IF "Horizontal resolution" is an extended property (OS dependent) are you saying this is calculated by the OS? RE: "AIUI, related to the combination of picture and output device/medium"

BTW: while I CAN see Horizontal Resolution by using:

File Properties > Summary (via Explorer)

which looks like the OS is aware of this, it does NOT come out as an extended property.

Gerry
 
>which looks like the OS is aware of this,

No, not directly - this is a custom property sheet, handled by a custom property sheet handler rather than by the shell itself.

In Vista almost all the custom property sheet properties introduced via (MS) custom handlers since the release of XP have been included directly in the shell instead, thus making them accessible as extended properties.
 
I don't think it's calculated. If I'm honest, I think it's made up.

When I take a picture with film in a camera, the picture ends up whatever size I choose it to be when I print it. Why is digital stuff any different? The size of images, displayed or printed depends very much on the hardware and application used and little, or not at all, on the nominal dpi (and only jpegs, amongst major graphics formats, even claim to have such a property).

My Windows machine is set at (the default) 96dpi - this means, in theory, that my display uses 96 dots (pixels) to display what it thinks is an inch. Programs such as Word use this to determine how to display at different Zoom percentages. I don't know, for sure, the dot pitch of my monitor but I think it's 0.26mm, which means 97.7 of them measure an inch. I used to have a 5:4 ratio monitor that I ran at a 4:3 resolution, which further complicated things. This stuff gets very complicated very quickly, and I haven't even mentioned printers and scanners (some of which claim to scan at 2400dpi or more - using interpolation, of course - they can't do it optically).

The size of a printout is, to some extent, a matter of preference and whilst the "Dimensions" (in pixels) may help ricardo1023 identify those he wants to print large, I think it unlikely that the dpi will help.



Enjoy,
Tony

------------------------------------------------------------------------------------
We want to help you; help us to do it by reading this: Before you ask a question.

I'm working (slowly) on my own website
 
Tony said:
and only jpegs, amongst major graphics formats, even claim to have such a property).

Mmmmmmm, negative. The file I am using for testing is a BMP. Windows Explorer, as stated has a Horizontal Resolution of "96 dpi". Corel states it is 72 dpi. TIFF files...also have DPI. So I am not sure where you are getting that idea.

That being said, it is kind of meaningless. It is "dots-per-inch", and it is either a printer or graphics card issue. Although, it is not so meaningless, as those are the methods we use to look at things.

Heck, I don't know.
Tony said:
I haven't even mentioned printers
What is this? Another Tony moment? JUST KIDDING! The issue for the OP is printing. Which is where DPI is seriously a factor.

If a file is printed to a LARGE format, then just about all professional printers will require a 300 DPI image file. Simply because if you are printing, say, an 18" x 24" print (I just did one recently), it makes a heck of difference if the file is 72 DPI vs 300 DPI.

If both are printed to 18" x 24", the lower DPI file will definitely come out pixelated. BTW: the file was 7200 x 5400 (pixels).

It is a rare originating digital imaging source that produces output to 300 DPI.

Gerry
 
>Mmmmmmm, negative.

The fact that the OS returns a DPI setting is nothing to do with whether the file type in question actually supports such a property. All of the basic graphic file formats (BMP, GIF, PNG, JPG, TIFF) are well defined, and a number of them do not include DPI. Thus the DPI returned by the OS for those formats is either made up or a default (e.g. current screen DPI setting) rather than a genuine value. And this is what Tony is getting at.
 
OK, printing :)

Everything you say is true - blowing up images beyond the information actually contained within them results in a grainy print - it's called pixelation on computers but the effect is not new - although modern top-end graphics packages can do a pretty good job of filling in the gaps.

None of that really changes the fact that dpi is essentially meaningless as a property of a file alone, and, as you point out, is not even reported consistently. Most applications will do some sort of scaling appropriate to the output medium. The result of printing an image 7200 x 5400 on a 24" x 18" piece of paper will be exactly the same regardless of any claimed dpi for the file.


Enjoy,
Tony

------------------------------------------------------------------------------------
We want to help you; help us to do it by reading this: Before you ask a question.

I'm working (slowly) on my own website
 
strongm, true.

Tony, true.

My point (sort of) was that the printer required that I scale the original file to 300 DPI. The original was 4752 x 3168 @ 72 DPI.

Scaling to 300 DPI made the file 7200 x 5400. I agree the file does not have a REAL property of "DPI". However, the issue the OP has is that they wish to identify which files are at 300 DPI in order to determine if said file is appropriate for a specific print job.

In any case, it appears that this is not possible for the OP, as "DPI" is non-extractable as information.

Gerry
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top