Change DPI while keeping resolution

[wazz3r]

Hello.

I'm trying to change the DPI of an EPS image that is converted to a PSD image with density 300.

The EPS is 475x1000 px.

If I run

Code: Select all

convert test.epx test.psd

I get a PSD file that is 475x1000 px and 72 DPI.

I want a PSD that is 475x1000px and 300 DPI. I tried with -resample 300 and -density 300, but after those command, the resolution have changed.

Ex.

Code: Select all

convert test.eps -strip -resample 300x300 test.psd

produces a PSD that is 1979x4167 AND 300 DPI.

How can I keep the resolution of the image and just change the DPI?

[wazz3r]

I found my error now.

There is a differences between

Code: Select all

convert -density 300 in.eps out.psd

and

Code: Select all

convert in.eps -density 300 out.psd

where the later produces the result i wanted.

[anthony]

The later sets output density, That is read at 72 dpi an doutput at 300dpi without changing the pixel size of the image.
Essentially you have 'compressed' the image in terms of 'real-world size' but not in number of pixels.

[Jimbo]

I just tried this technique with an .exr image, and did not get the same results.

The image I read in was 10240 x 4542 by 72 dpi.

After running this command:
convert -density 180 input.exr output.exr

The resulting image was exactly the same.

I also tried this command:

convert -units PixelsPerInch -density 180 input.exr output.exr

And the results were not affected.

I have not found a way to change the dpi on an exr image, yet in the openEXR docs, it says that dpi is supported.

Has anyone else tried this? I am thinking of trying this same setup while using a -resize that will not resize the image, like this:

convert -units PixelsPerInch -density 180 -resize 100 input.exr output.exr

Thoughts? Suggestions welcome.

I am running ImageMagick-7.0.8 on a Mac OSX 10.14.5 (Mojave).

- Jimbo

[fmw42]

Using density before reading the image is only for vector formats such as PDF, EPS, PS, etc. It makes no sense or affect on raster images.

Apply the density after reading a raster image such as EXR. But you may need special defines for EXR output. See EXR format information at https://imagemagick.org/script/formats.php

[Jimbo]

.exr is now an adapted image format for printing. Hence the dpi concern. Plus, some tools like Nuke and photoshop have size limitations and ImageMagick does not. Photoshop has a limit of 1000 inches and will not read-in the image properly (substituting white) with something more. Nuke has a hard-coded limit of 65169 pixels in any direction.

Many of our clients are asking for VERY large resolutions (currently working on one greater than 140K), and the client's specification requires the dpi to be set on delivery.

So, yes, perhaps it makes no sense, but I'd like to deliver what they ask for no matter how silly it might seem.

DPI has long been used for specifying photos and graphics for print.

- Jimbo

[fmw42]

But your command is incorrect syntax for ImageMagick. You need to specify the density after reading a raster image. If it does not set the density for EXR output, then you will have to request an enhancement. How are you determining that the output density is incorrect -- what tool? Have you tried EXIFTOOL?

[fmw42]

I tried setting the density and units with ImageMagick. But neither it nor exiftool report either of them.

Code: Select all

convert doll_small.exr -units pixelsperinch -density 72 x.exr

identify -verbose x.exr
Image: x.exr
  Format: EXR (High Dynamic-range (HDR))
  Class: DirectClass
  Geometry: 500x489+0+0
  Units: Undefined
  Colorspace: RGB
  Type: TrueColorAlpha
  Base type: Undefined
  Endianess: Undefined
  Depth: 16-bit
  Channel depth:
    red: 16-bit
    green: 16-bit
    blue: 16-bit
    alpha: 1-bit
  Channel statistics:
    Pixels: 244500
    Red:
      min: 0  (0)
      max: 60255 (0.919432)
      mean: 1493.15 (0.0227839)
      standard deviation: 4391.14 (0.0670045)
      kurtosis: 30.1437
      skewness: 4.79882
      entropy: 0.782034
    Green:
      min: 0  (0)
      max: 60223 (0.918944)
      mean: 1378.18 (0.0210297)
      standard deviation: 4307.43 (0.0657272)
      kurtosis: 34.3748
      skewness: 5.146
      entropy: 0.766154
    Blue:
      min: 0  (0)
      max: 60223 (0.918944)
      mean: 1229.18 (0.018756)
      standard deviation: 3984.48 (0.0607993)
      kurtosis: 41.2023
      skewness: 5.55276
      entropy: 0.753766
    Alpha:
      min: 65535  (1)
      max: 65535 (1)
      mean: 65535 (1)
      standard deviation: 0.000690535 (1.05369e-08)
      kurtosis: -3
      skewness: 3.03698e+09
      entropy: 4.82164e-05
  Image statistics:
    Overall:
      min: 0  (0)
      max: 65535 (1)
      mean: 17408.9 (0.265642)
      standard deviation: 3170.76 (0.0483828)
      kurtosis: -0.727883
      skewness: 1.10911
      entropy: 0.5755
  Rendering intent: Undefined
  Gamma: 1
  Background color: rgba(255,255,255,1)
  Border color: rgba(223,223,223,1)
  Matte color: rgba(189,189,189,1)
  Transparent color: rgba(0,0,0,0)
  Interlace: None
  Intensity: Undefined
  Compose: Over
  Page geometry: 500x489+0+0
  Dispose: Undefined
  Iterations: 0
  Compression: Undefined
  Orientation: Undefined
  Properties:
    date:create: 2019-08-27T04:17:06+00:00
    date:modify: 2019-08-27T04:17:06+00:00
    signature: 8329f630012128a94d512254a6b36d9107005969307bea886f6c49557df3ab92
  Artifacts:
    filename: x.exr
    verbose: true
  Tainted: False
  Filesize: 1.87316MiB
  Number pixels: 244500
  Pixels per second: 17.6911MB
  User time: 0.020u
  Elapsed time: 0:01.013
  Version: ImageMagick 6.9.10-62 Q16 x86_64 2019-08-25 https://imagemagick.org

exiftool -s -ee -g1 -u -n -D x.exr
---- ExifTool ----
    - ExifToolVersion                 : 10.51
---- System ----
    - FileName                        : x.exr
    - Directory                       : .
    - FileSize                        : 1964155
    - FileModifyDate                  : 2019:08:26 21:17:06-07:00
    - FileAccessDate                  : 2019:08:26 21:17:10-07:00
    - FileInodeChangeDate             : 2019:08:26 21:17:06-07:00
    - FilePermissions                 : 644
---- File ----
    - FileType                        : EXR
    - FileTypeExtension               : EXR
    - MIMEType                        : image/x-exr
    - ImageWidth                      : 500
    - ImageHeight                     : 489
---- OpenEXR ----
    - EXRVersion                      : 2
    - Layout                          : 0
    - Channels                        : A half 1 1, B half 1 1, G half 1 1, R half 1 1
    - Compression                     : 0
    - DataWindow                      : 0 0 499 488
    - DisplayWindow                   : 0 0 499 488
    - LineOrder                       : 0
    - PixelAspectRatio                : 1
    - ScreenWindowCenter              : 0 0
    - ScreenWindowWidth               : 1
---- Composite ----
    - ImageSize                       : 500x489
    - Megapixels                      : 0.2445

What version of OpenEXR is supposed to support density and units? I was using v2.3.0

[Jimbo]

Fred,

Thank you for your replies. I tried this:

convert -units PixelsPerInch input.exr -density 180 output.exr

and that re-sized the image's overall resolution by the equivalent ratio of input/output dpi (eg. 180/72), but did not alter the dpi.

You might be right about exr support dpi. I have not found anything in the spec as of yet. Trying to confirm with an engineer I know.
[Confirmed. Exr does not natively support dpi.]

I'm willing to try using -set to add to the exr's meta-data to see if other software could recognize a dpi <integer> declaration.

Currently, trying to use alternate image formats. Tiff has a "Maximum TIFF file size" and can't be used. Trying PSD which has all the settings I need as long as I keep the pixel dimensions/dpi under 1,000 inches.

My convert call looks like this for now (the input image will eventually be 146880x65160):

convert -alpha off -units PixelPerInch input.exr -density 180 -depth 32 out.psd

If you have any other 16bit half-float or 32 bit image formats to suggest, I'm all ears.

- Jimbo

[fmw42]

Pixel size should not be affected by either -units or -density. So I do not understand your comment about it resizing the image.

Units and -alpha should also be set after reading in the raster input. So your command should be

Code: Select all

convert input.exr -alpha off -units PixelPerInch -density 180 -depth 32 out.psd

But -units and -density should have no affect.

PFM supports float pixel data. See http://netpbm.sourceforge.net/doc/pfm.html.

Also HDR format, which I have used for tone mapping. See https://en.wikipedia.org/wiki/RGBE_image_format and https://floyd.lbl.gov/radiance/refer/filefmts.pdf. ImageMagick supports this format for both reading and writing. See https://imagemagick.org/script/formats.php. See the "lamp" hdr image in my tone mapping scripts on my web site at the link below.

[Jimbo]

Because of the 1000 inch limit imposed by Photoshop, I have to include dpi settings in order for my final image not to go beyond this limit.

I've gotten this to work, much in the same way your example reads, but have run into another problem.

Turns out IM only supports output of 8 and 16 bit versions of PSD/PSB files and unfortunately that allows the quantum setting to clamp the color depth of true HDR images.

So, waiting for a new release with 32 bit PSD/PSBs being created without clamping the highs and lows of the HDR.

Cheers.
- Jimbo

[fmw42]

Have you tried using Q32 or Q16 HDRI compiles of ImageMagick?

[Jimbo]

This is what I am using:

Version: ImageMagick 7.0.8-59 Q16 x86_64 2019-08-05 https://imagemagick.org
Copyright: © 1999-2019 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC HDRI Modules OpenMP(3.1)
Delegates (built-in): bzlib freetype heic jng jp2 jpeg lcms ltdl lzma openexr png tiff webp xml zlib

I am not sure which of the HDRI builds I have.
- J

[Jimbo]

I sent a message to Weary Wanderer to see if he would clue me in on how the header needs to be output for the psd 32 bit depth, so I could try the compile that he did a few weeks ago, but I will need to want on that. Doubt if I could figure it out without a similar example.

- J

[fmw42]

Your version of ImageMagick is Q16 HDRI. So it should write data outside the quantum range, if the output format supports that. Have you tried Q32 IM 7 with HDRI?

I am unaware whether IM can write 32-bit single channel PSD images. One of the developers will need to comment.