why does a 1024x1024 pixel image when placed in a 1024x1024 InDesign document need resizing?

[Ian D361303828pe2]

I am new to InDesign and have to say I'm finding it a complete nightmare.  What happened to consistency between Adobe products?  It's a complete mess of inconsistencies when compared with Photoshop.

Anyway, first issue (of many) is I want to create a PDF booklet for the web using images that are sized 1024 pixels by 1024 pixels.  In Photoshop these have been created at 96ppi.

InDesign gives me no options to specify ppi - just the number of pixels.  When I "Place" the correctly sized image InDesign imports it at a smaller size and I have to waste time resizing and positioning it?

Why?  This is a VERY basic common sense function.  I tried changing the ppi in Photoshop to 72ppi (without resampling to ensure the image was still 1024 pixels) in case this was an issue as Mac vs Windows seems to set different ppi sizes for no sensible reason I can think of but that just came in even smaller, requiring even more resizing.

How do I fix this?

[Robert at ID-Tasker]

@rayek.elfin:

>InDesign needs a fix to identify these type of JPG files and avoid importing 72PPI files as 144PPI.

Unless you're experiencing a different bug from discussed here, then the problem is that InDesign places such images scaled at 50% (which results in the effective resolution of 144 ppi, as also pointed by @rob day ). InDesign correctly reports their actual resolution as 72 ppi.

By @leo.r

But bigger JPEG = higher Effective PPI:

[rob day]

If by bigger you mean a larger pixel dimension then yes, but neither Export or Save As affect the placed JPEG’s pixel dimensions.

[Robert at ID-Tasker]

If by bigger you mean a larger pixel dimension then yes, but neither Export or Save As affect the placed JPEG’s pixel dimensions.

By @rob day

No one argues, that placed JPEG will have all of its pixels - but it will be scaled down.

[rob day]

But its a trivial move to scale it to the page and get the same Effective res—could be done with a drag out on Place, an Object Style, script...

[Robert at ID-Tasker]

But its a trivial move to scale it to the page and get the same Effective res—could be done with a drag out on Place, an Object Style, script...

By @rob day

Yes, it's trivial - but it's a bug.

And now we need to remember about it when creating scripts that import JPEG images...

[Robert at ID-Tasker]

But its a trivial move to scale it to the page and get the same Effective res—could be done with a drag out on Place, an Object Style, script...

By @rob day

How can you do that with ObjectStyle?

You can't set "100%" in Size & Pos and Fitting also won't work?

Unless I'm missing something?

[rob day]

Place the JPEG into a frame set to Auto-fit rather than directly on the page.

When I place via a script I don‘t think there’s  a way of of knowing in advance what the output dimensions of any image is, so I always have to set the bounds of the parent frame after the place and then set the fitting. I don’t see why I would have to make an exception for JPEG.

[Robert at ID-Tasker]

Place the JPEG into a frame set to Auto-fit rather than directly on the page.

When I place via a script I don‘t think there’s  a way of of knowing in advance what the output dimensions of any image is, so I always have to set the bounds of the parent frame after the place and then set the fitting. I don’t see why I would have to make an exception for JPEG.

By @rob day

Yes, if you know the finall size - and you don't have to care about the final scale / size...

But what if you need to import images instead of "tags" in the text?

Maybe not "tags" but someone have list of file names in separate paragraphs and needs to import them as InLine objects.

Or your frame is just a "window" and after placing you need to center it - because user knows how much should be cropped... so you can't use auto-fitting...

Or after placing you need to align it with an edge or corner...

Without extra check for scale - you script will place images inccorrectly.

Or - you are doing "imposition" from some random JPEG files - and somehow their size will be mulitple of 1024...

[rob day]

Without extra check for scale - you script will place images inccorrectly.

Ok, if you want to be sure the scale is 100% add the scale line. Here’s an example with no checking that would place any of the JPEG iterations as well as any other format at 100% on the 1024x1024 page. In all cases the Effective res is 72ppi.

var f = File.openDialog("Select the file", "");
var ap = app.activeWindow.activePage
var img = ap.place(File(f));
img[0].parent.geometricBounds = ap.bounds
img[0].verticalScale = img[0].horizontalScale = 100
//or img[0].parent.fit(FitOptions.FILL_PROPORTIONALLY)

//Or this if you just want to ensure the place at 100% on any sized page
var f = File.openDialog("Select the file", "");
var ap = app.activeWindow.activePage
var img = ap.place(File(f));
img[0].verticalScale = img[0].horizontalScale = 100;
img[0].parent.fit(FitOptions.FRAME_TO_CONTENT)

[leo.r]

> But bigger JPEG = higher Effective PPI:

I see. Then what I wrote should be changed as:

"InDesign places such images scaled at 50% or more, depending on their pixel dimensions (which results in their effective resolution increased accordingly)". 

[rayek.elfin]

Well, yes, of course. Perhaps I should have reworded it as "interprets 72PPI 1024 by 1024 px JPG files that are saved with Photoshop's Save As--->JPG or SFW-->JPG with fully embedded meta data"

And effectively scaling those to 50%.

[Robert at ID-Tasker]

Well, yes, of course. Perhaps I should have reworded it as "interprets 72PPI 1024 by 1024 px JPG files that are saved with Photoshop's Save As--->JPG or SFW-->JPG with fully embedded meta data"

And effectively scaling those to 50%.

By @rayek.elfin

But for bigger files - scaling down is even greater:

[Peter Spier]

Apropos of nothing at all, I've been skimming this thread and one thing jumped out at me -- the 1024 multiple and I'm thinking this is a common multiple for actual monitor screens. I wonder if there is any connection.

[rayek.elfin]

It is also important to point out that InDesign has no issues with 1024px square JPG files that either embed the PPI using Xmp meta data properties or no meta data at all.

Only with Photoshop's Exif Save As-->JPG.

When I remove Photoshop's meta data and the Exif meta data and generate Xmp meta data to embed the 72PPI x and y resolution property via PhotoLine: InDesign places the file correctly.

[Derek Cross]

Is it just me, but is there a touch of “how many angels can dance on the head of a pin?” about this thread?

[rayek.elfin]

Well, perhaps a tad 😉

Solutions are pretty simple for the OP, even with CS6:

• save as PNG or TIFF files and import those instead of JPG. Then during document export ensure lossy image export for PDF or ePub.
• batch-convert all JPG files to remove Exif data before import into InDesign (via Exiftool, for example). InDesign understands the secondary Photoshop resolution meta data just fine.

Still, it *is* a rather odd case.

[rob day]

Solutions are pretty simple

Or, simply set the scale to 100% in the ID Transform panel.

[Robert at ID-Tasker]

Well, perhaps a tad 😉

Solutions are pretty simple for the OP, even with CS6:

• save as PNG or TIFF files and import those instead of JPG. Then during document export ensure lossy image export for PDF or ePub.
• batch-convert all JPG files to remove Exif data before import into InDesign (via Exiftool, for example). InDesign understands the secondary Photoshop resolution meta data just fine.

Still, it *is* a rather odd case.

By @rayek.elfin

Or do not do Save As but Save For Web.

Which is why I never had this problem before - and discovered it at the beginning of this thread - as I always do Ctrl+Shift+Alt+S - never Save As - for JPEGs / PNGs / GIFs.

[James Gifford—NitroPress]

I'm visualizing Hampsterdance, myself. I still feel it's all about a notion of theoretical/technical perfection that is eclipsed by simple reality of process.

[rob day]

I'm visualizing Hampsterdance, myself.

Or maybe Mountain Out of a Molehill?

[Brad @ Roaring Mouse]

Agreed. The "effect" seems to only happens if a) the file is JPG b) it was saved (Save As) from Photoshop (so it has embedded PS metadata) and  c) with an EXIF embedded resolution setting of EXACTLY 72ppi.

It also depends on the actual pixel dimesnsion as to whether it does the scaling or not, and how much. e.g. a file less than 768 px will not scale... it will drop at 100% at effective 72ppi. From 768 to about 2048, it scales to 50% (effective 144ppi). As the file gets bigger than a certain threshold of pixel dimension, the scaling changes accordingly. e.g. a 3000 x 3000 image wil drop at a scale of 20% (effective 360ppi), 10000 x 10000 wiill drop at 10% (effective 720ppi), and so on up the scale. 

Now I can see why the engineers thought doing this would be a good idea, as it keeps images with at 72ppi at a reasonable dimension when dropped on the page, but why they designed it to affect only PS JPGs with embedded metadata is beyond me. With the plethora of digital camera images being saved with an EXIF of 72ppi, I can see how this would help out so why limit it to PS files, and why only JPG and not TIFF/PNG/PSD/etc?

AND Plus, (I'd like to know what drugs the coder was on when they decided on how this was applied): e.g. in my tests (I had some time on my hands, obviously), a 2048x2048 image will drop at effective 144, but go one pixel different either direction and you get this: a 2047x2047 will drop at 72, and a 2049x2049 will drop at 216!!

[rayek.elfin]

Brad @ Roaring MouseI had planned to test 2048px square as well, because I had an inkling it would respond the same. But you beat me to it!

Agreed: it almost seems intentional. Or it's an accidental unintended calculation error of some sort in the programming.

Still quite interesting and odd.

[rob day]

Now I can see why the engineers thought doing this would be a good idea, as it keeps images with at 72ppi at a reasonable dimension when dropped on the page

Hi Brad, the flakey JPEG behavior has been around for at least 10 years, and personally I hope they never transfer it to the more useful PSD format. 

I’m not sure how you would define a reasonable dimension, but a script could place an image scaled to a specified Effective Resolution. The example below places and scales all image formats to an Effective res of 300ppi. However, this might not be expected for someone designing for screens like @Ian D361303828pe2 , who wants the image to place at the 1024 x 1024px page dimensions (14.22" x 14.22"). In the end the user still has to understand that InDesign resolution is scaled not resampled.

var er = 300
var f = File.openDialog("Select the file", "");
var ap = app.activeWindow.activePage
var img = ap.place(File(f));
if (img[0].hasOwnProperty("actualPpi")) {
    var s = img[0].actualPpi;
    app.layoutWindows[0].transformReferencePoint = AnchorPoint.TOP_LEFT_ANCHOR;
    img[0].verticalScale = (s[0]/er)*100
    img[0].horizontalScale = (s[1]/er)*100;
    img[0].parent.fit(FitOptions.FRAME_TO_CONTENT)
}

[Brad @ Roaring Mouse]

"Hi Brad, the flakey JPEG behavior has been around for at least 10 years"

Yup. as you already mentioned, it's been in InDesign since CC was rolled out. CS6 or less doesn't do it.

Since i had TOO much time on my hands, I went on a deeper rabbit hole to see what was the earliest version of PS that would save a JPG with the "trigger" metatdata, and it is PS 6 (sort of, but not always) and then the first CS version for sure. I found the trigger is that BOTH these things have to appear in the JPG, i.e. the EXIF resolution AND the PS metadata. If either one is deleted, the JPG places at 100% at 72ppi.

Also, if you open a PS JPG in any other program and do a small change, but just "Save" instead of "Save As", the PS metadata can remain intact even if it came from, say, GraphicConverter.

As with all things, I guess a simple answer is to incude a preference in ID to tailor the behaviour to an individual's preference because there's no set answer that would solve everybody's issues with this... I certainly don't need it. I have always just drag-dropped anyway (i.e. pulling out a graphic frame), knowing the pitfalls to simply dropping a 72 dpi JPG. We have bigger things to worry about 😉