Generating a spreadsheet

[rambo3]

Hey gang,

Apologies in advance since I'm sure variations on this question have been asked here multiple times before. I did read the FAQ and do a search but it was a lot of information to wade through and I'm a bit short on time.

I'm looking to generate a spreadsheet with information about ~100 images. The relevant information would ideally be the filename, the color profile, and the dimensions in picas. Is ExifTool a good tool for this purpose? If so, I'll dig in deeper and see if I can learn how this tool works.

Thanks,
Rambo3

[StarGeek]

I'm on mobile atm so I can't go into details, but take a look at the CSV option.  You can export the tags you want and load the results into a spreadsheet.  Check faq 12.

[rambo3]

Interesting, looking deeper. Is it possible to display dimensions in picas rather than pixels?

[Hayo Baan]

Is it possible to display dimensions in picas rather than pixels?

No, not by default, but you could for instance create a custom tag to do that for you. Then again, you can do this in the spreadsheet quite easily too, of course.

Why do you want picas anyway? They would also require you to take the pixels per inch into consideration and that could be a different number for each image. Or do you want a default ppi to be used for the calculation for all images?

[StarGeek]

.
They would also require you to take the pixels per inch into consideration and that could be a different number for each image. Or do you want a default ppi to be used for the calculation for all images?

I was looking into this as best I could on mobile and found a post on Adobe's forum that used 72 as the default res. which seems reasonable.

[Stephen Marsh]

More here:

https://www.prepressure.com/design/basics/points

Since the DTP revolution, a PostScript point of 1/72in has become the "standard", however this was not always so (so 12 points in a pica, 6 picas to the inch).

[Stephen Marsh]

As a start point:

exiftool -ICCProfileName -FileName -csv 'INPUT_DIR_or_FILE_PATH' > 'OUTPUT_PATH_and_FILENAME.csv'

You may also be able to use -ProfileDescription instead of -ICCProfileName

Some files may not contain "print size" metadata, so there may only be a width/height value in pixels... To find what tags are in your files you can use:

exiftool -a -G1 -s 'path/to/file or directory'


(Win OS would use straight double quote marks " rather than single, no need for quote marks if there are no word spaces in the file path or name)


So, adding -ImageWidth -ImageHeight would include the pixel dimensions:

exiftool -ICCProfileName -FileName -ImageWidth -ImageHeight -csv 'INPUT_DIR_or_FILE_PATH' > 'OUTPUT_PATH_and_FILENAME.csv'

[StarGeek]

Here's my attempt at a Pica config file.  It creates an XPica and YPica tag.  If ResolutionUnit is not defined, it assumes inches.  If X/YResolution are not defined, it assumes 72, which can be changed by altering the $DefaultRes variables in both spots in the config file.

This is a subject I am completely unfamiliar with, so if I've made a mistake, please let me know.  I've taken the Image Width/Height, divided that the X/Y Resolution.  That should give me inches (or cm if defined as such by ResolutionUnit).  That is then divided by 6 as there are 6 picas/inch, from what I've read.  If the ResolutionUnit is cm, then it's divided by 2.362 (6 pica/inch and 2.54 cm/inch, 6/2.54=2.362).

To use it, the very first option must be -config /path/to/Pica.Config. 

Edit: updated to correct error 'cuz math R hard

Edit: second update, fixed error where I assumed variable was printConv value.  Now should handle centimeter ResolutionUnit properly.

[rambo3]

Hey everyone,

Thanks so much for all of the replies. Unfortunately, I haven't been able to devote time to this today but hopefully will be able to dig in deeper tomorrow.

Regarding picas: I'm working at a Publisher and that's the standard unit of measure here. It makes certain things much more difficult than they would be otherwise. 

[Stephen Marsh]

StarGeek,

For my test image (1890x1417px), the size is 16x12cm / 6.3x4.723in / 453.6x340.1pt / 37.8x28.34picas @ 300ppi

The config file is generating the following:

Code Select Expand

X Pica : 1.05
Y Pica : 0.787222222222222

When my expectation is: 37.8x28.34

[Stephen Marsh]

OK, I had to change the base unit for both the X and Y to:

my $Pica2In=0.167;
my $Pica2Cm=0.42;

Then the (close to expected values of 37.8x28.34 as defined by Adobe Photoshop) result was returned:

Code Select Expand

X Pica : 37.7245508982036
Y Pica : 28.2834331337325

[StarGeek]

Yeah, I see my mistake now.  I divided where I should have multiplied.  The other way to fix would be to change the return lines:
return ($val[2]/$Res * ($val[1] eq 'cm' ? $Pica2Cm : $Pica2In ) );

[Stephen Marsh]

Much better than my hack StarGeek!

[StarGeek]

Stephen, can you figure out what Photoshop uses as a default res for files that don't have X/YResolution?  It'd be nice to fix up the config to default to that.

[Stephen Marsh]

Hi StarGeek, I believe that the answer to life, the universe and everything = 72 (42 was apparently a misquote)!

You had already assumed the same as Adobe, so all good there I think!