We are using the open source image manipulation tool ImageMagick to take thumbnails of various files. We thought things were running pretty smoothly with all this, until we realized that some browsers (namely Internet Explorer 8 and Chrome) were unable to display the JPEG files.
I can only assume that the output of the ImageMagick conversions are not web safe JPEGs. Why is this the case, and can it be fixed at all?
Incidentally, we are using the command line tool convert and we are using these parameters:
convert -thumbnail 150x fileToThumb outputPath
EDIT:
Image: 50afd2b1-e42c-4e90-9244-9c5a00c1933d.jpg
Format: JPEG (Joint Photographic Experts Group JFIF format)
Class: DirectClass
Geometry: 150x212+0+0
Resolution: 72x72
Print size: 2.08333x2.94444
Units: PixelsPerInch
Type: ColorSeparation
Endianess: Undefined
Colorspace: CMYK
Depth: 8-bit
Channel depth:
cyan: 8-bit
magenta: 8-bit
yellow: 8-bit
black: 8-bit
Channel statistics:
cyan:
min: 0 (0)
max: 255 (1)
mean: 28.492 (0.111734)
standard deviation: 61.879 (0.242663)
kurtosis: 5.32422
skewness: 2.47138
magenta:
min: 0 (0)
max: 255 (1)
mean: 43.5579 (0.170815)
standard deviation: 72.7733 (0.285386)
kurtosis: 1.31682
skewness: 1.57362
yellow:
min: 0 (0)
max: 255 (1)
mean: 53.0706 (0.20812)
standard deviation: 85.3198 (0.334587)
kurtosis: -0.0841614
skewness: 1.2581
black:
min: 0 (0)
max: 52 (0.203922)
mean: 0.149434 (0.000586016)
standard deviation: 1.78161 (0.00698672)
kurtosis: 364.996
skewness: 17.91
Image statistics:
Overall:
min: 0 (0)
max: 255 (1)
mean: 25.054 (0.098251)
standard deviation: 61.3102 (0.240432)
kurtosis: 5.28177
skewness: 2.5304
Total ink density: 300%
Rendering intent: Undefined
Interlace: None
Background color: white
Border color: cmyk(223,223,223,0)
Matte color: grey74
Transparent color: black
Page geometry: 150x212+0+0
Dispose: Undefined
Iterations: 0
Compression: JPEG
Quality: 92
Orientation: Undefined
Properties:
create-date: 2009-08-17T11:38:16+01:00
jpeg:colorspace: 4
jpeg:sampling-factor: 1x1,1x1,1x1,1x1
modify-date: 2009-08-17T11:37:48+01:00
signature: f5e85add196c10f1d73f416482e779245595a644877696fffb2637b5b97f6b9c
Artifacts:
verbose: true
Tainted: False
Filesize: 20.5kb
Number pixels: 31.1kb
Version: ImageMagick 6.5.3-10 2009-06-19 Q16 OpenMP http://www.imagemagick.org
Here is the identify output (also noticed that this JPEG image displays as a solid black image on the Mac):
[Where is this image ???]
Check that the colorspace of the JPEG is RGB, browsers won't like any other colorspace.
To check it, use the ImageMagick identify command
identify -verbose path/to/jpeg.jpg
The output should start off like this (it's about 50 lines long typically)
Format: JPEG (Joint Photographic Experts Group JFIF format)
Class: DirectClass
Geometry: 467x330+0+0
Type: TrueColor
Endianess: Undefined
Colorspace: RGB <----you are looking for this
Depth: 8-bit
...
If you've got a different colorspace (e.g. CMYK), you can use -colorspace RGB in your convert command line to force the RGB colorspace to be used.
If that does not help, you might want to paste the entire output of the identify command into your question as that will greatly aid diagnosis.
You can use the following command to convert cmyk to rgb
http://imagemagick.org/Usage/formats/#color_profile
convert cmyk_image.jpg -colorspace
rgb rgb_image.jpg
g.b.1981 answer is OK, but I have to add: for me it works reliably only when adding -type truecolor:
convert cmyk.jpg -colorspace rgb -type truecolor rgb.jpg
Related
I've already asked this question I did not get satisfactory answers, So I did more research and I'm putting this question forward in a better way. I read an image through OpenCV``imread method. And I saved it using imwrite method. It increases the output file size by more than double.
Below are the details of the images which I obtained from imagemagick (I did not write all the details down, I'm attaching the images for all the details are needed):
Input Image:
Format: JPEG (Joint Photographic Experts Group JFIF format)
Mime type: image/jpeg
Class: DirectClass
Geometry: 1836x3264+0+0
Resolution: 72x72
Print size: 25.5x45.3333
Units: PixelsPerInch
Type: TrueColor
Endianess: Undefined
Colorspace: sRGB
Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
Channel statistics:
Pixels: 5992704
Compression: JPEG
Quality: 75
Filesize: 267KB
Number pixels: 5.993M
Output Image:
Format: JPEG (Joint Photographic Experts Group JFIF format)
Mime type: image/jpeg
Class: DirectClass
Geometry: 1836x3264+0+0
Units: Undefined
Type: TrueColor
Endianess: Undefined
Colorspace: sRGB
Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
Channel statistics:
Pixels: 5992704
Compression: JPEG
Quality: 95
Filesize: 611KB
Number pixels: 5.993M
As you can see, the input image size is 267KB but the output image size turned out to be 611KB. Now I know that its size depends on the encoder, Compression value, bit-rate etc.
I want to know is there anyway I can save the image in the exact same size of the input image.
I also tried using the compression in openCV like this
cv2.imwrite('result.jpg', image, [int(cv2.IMWRITE_JPEG_QUALITY), 45]).
Here the image quality would be 45, but the image size would still be greater than the input image (around 300KB).
I don't want to go less than 45 because it would affect the image details and loss of data.
I tried using external libraries like scipy, matplotlib. But they all bump the image size regardless.
Any clue on why the output image increase and how we can fix it is very much appreciated.
Here is some code for reference
import cv2 #opencv library for image processing implementations
def main():
im = cv2.imread('sample.jpg')
cv2.imwrite('result.jpg', im)
if __name__=='__main__':
main()
And here is the image for reference.
Your original image has quality 75. If you don't define the quality of saving with OpenCV it defaults to 95, so you should expect the file to be larger.
If you want to set it to some maximum size, you can use ImageMagick like this to set it to, say 300kB:
convert sample.jpg -define jpeg:extent=300k a.jpg
And that gets you a 299,810 byte file with quality 83.
If you are prepared to permit 400kB, you can use:
convert sample.jpg -define jpeg:extent=400k a.jpg
and that gets you a 358,000 byte file with quality 93.
I wrote something similar in Python that lets you save at a specified size using a binary search here.
The solution for this will be, saving an image using imageio.imwrite, this worked for me, when I was doing image compression. while saving a compressed image file using CV2 it increased the compressed image size more than the original image size. imageio.imwrite solved this issue for me
example: imageio.imwrite("image_name.jpg", cv2_image)
The increase in file size while saving with jpg is that it decompresses the image file
I am using this command to flatten 3 images in a folder.
for pos1 in 1*.png; do for pos3 in 3*.png; do for pos6 in 6*.png; do convert -gravity center $pos1 $pos3 $pos6 -layers flatten $pos1$pos3$pos6 ;done ;done ;done
this is how my folder looks:
For some reason, imagemagick ignores the 1*.png images and creates a composition of just $pos3 and $pos6. What could be the reason for this behaviour and how do I fix it? The images i am manipulating are the product of some older image magick manipulation.
UPDATE:
After some more testing it looks like that the error comes from the fact that the input images are the output of come previous convert / composite command (cant remember which one I used). Still, I don't know how to fix this problem.
identify command output (no histogram):
Format: PNG (Portable Network Graphics)
Mime type: image/png
Class: DirectClass
Geometry: 3843x3402+0+0
Units: Undefined
Type: TrueColorAlpha
Endianess: Undefined
Colorspace: sRGB
Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
alpha: 1-bit
Channel statistics:
Pixels: 13073886
Red:
min: 0 (0)
max: 255 (1)
mean: 246.072 (0.96499)
standard deviation: 44.204 (0.173349)
kurtosis: 23.2206
skewness: -4.96363
entropy: 0.0669139
Green:
min: 0 (0)
max: 255 (1)
mean: 246.072 (0.96499)
standard deviation: 44.2038 (0.173348)
kurtosis: 23.2205
skewness: -4.96362
entropy: 0.0669169
Blue:
min: 0 (0)
max: 255 (1)
mean: 246.072 (0.96499)
standard deviation: 44.2038 (0.173348)
kurtosis: 23.2207
skewness: -4.96364
entropy: 0.066917
Alpha:
min: 255 (1)
max: 255 (1)
mean: 255 (1)
standard deviation: 0 (0)
kurtosis: 0
skewness: 0
entropy: 0
Image statistics:
Overall:
min: 0 (0)
max: 255 (1)
mean: 184.554 (0.723742)
standard deviation: 38.2817 (0.150124)
kurtosis: 150.659
skewness: -25.8099
entropy: 0.050187
Rendering intent: Perceptual
Gamma: 0.45455
Chromaticity:
red primary: (0.64,0.33)
green primary: (0.3,0.6)
blue primary: (0.15,0.06)
white point: (0.3127,0.329)
Background color: white
Border color: srgba(223,223,223,1)
Matte color: grey74
Transparent color: none
Interlace: None
Intensity: Undefined
Compose: Over
Page geometry: 3843x3402+0+0
Dispose: Undefined
Iterations: 0
Compression: Zip
Orientation: Undefined
Properties:
date:create: 2017-04-05T20:18:59+02:00
date:modify: 2017-04-05T10:36:08+02:00
png:bKGD: chunk was found (see Background color, above)
png:cHRM: chunk was found (see Chromaticity, above)
png:gAMA: gamma=0.45454544 (See Gamma, above)
png:IHDR.bit-depth-orig: 8
png:IHDR.bit_depth: 8
png:IHDR.color-type-orig: 6
png:IHDR.color_type: 6 (RGBA)
png:IHDR.interlace_method: 0 (Not interlaced)
png:IHDR.width,height: 3843, 3402
png:sRGB: intent=0 (Perceptual Intent)
png:text: 2 tEXt/zTXt/iTXt chunks were found
png:tIME: 2017-04-03T18:20:37Z
signature: ea0ce8b483b92bda18d999d203a5e1329d48fb63059d6702051b74f7930286fc
Artifacts:
filename: /Users/mainuser/Desktop/final/HALFS/to/1_1ND1_1.png
verbose: true
Tainted: False
Filesize: 710KB
Number pixels: 13.07M
Pixels per second: 54.47MB
User time: 0.230u
Elapsed time: 0:01.240
Version: ImageMagick 6.9.7-3 Q16 x86_64 2017-01-07 http://www.imagemagick.org
Updated Answer
As we are having some problems and you can't share your images, let's make some of our own:
convert -size 600x200 xc:none -fill red -draw "circle 100,100 100,200" -bordercolor black -border 1 1.png
convert -size 600x200 xc:none -fill lime -draw "circle 300,100 400,100" -bordercolor black -border 1 2.png
convert -size 600x200 xc:none -fill blue -draw "circle 500,100 600,100" -bordercolor black -border 1 3.png
Now let's flatten them onto a transparent background:
convert [123].png -background none -flatten result.png
Maybe you can create these images and try with your version of ImageMagick.
Original Answer
It depends on how your files are in terms of size and transparency, but try this in the middle of your loop:
convert -gravity center "$pos1" "$pos3" -composite "$pos6" -composite "${pos1}${pos3}${pos6}.png"
This assumes that "$pos1" is the largest file in terms of pixel dimensions.
Note that you should always double quote shell variables when expanding them in case your filenames happen to have spaces in them.
This is not the answer to the original question but I found it because I had the same problem that images were just ignored when using convert.
My solution was allocate higher ressources in resources.xml as described in this solution.
Maybe this is useful to someone at some point.
So here is my source tif image:
$ identify -verbose source.tif
Image:
Format: TIFF (Tagged Image File Format)
Class: DirectClass
Geometry: 512x512+0+0
Resolution: 72x72
Print size: 7.11111x7.11111
Units: PixelsPerInch
Type: Palette
Base type: TrueColor
Endianess: MSB
Colorspace: RGB
Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 1-bit
And I've tried:
convert source.tif output.png
And here are the results:
$ identify -verbose output.png
Format: PNG (Portable Network Graphics)
Class: DirectClass
Geometry: 512x512+0+0
Resolution: 28.34x28.34
Print size: 18.0663x18.0663
Units: PixelsPerCentimeter
Type: Palette
Endianess: Undefined
Colorspace: RGB
Depth: 8-bit
Channel depth:
red: 8-bit
green: 8-bit
blue: 1-bit
But I'm not seeing how to make the PNG be RGBA16. Which as I understand means it needs a 16 bit depth, and an alpha channel.
In general, ImageMagick will use the most economical output format that is compatible with your specifications. So, if your input image doesn't have an alpha channel (i.e. transparency), your output image won't have transparency. If a 256-colour palette is adequate for the colours in your image, it will create a palettised output image. If an 8-bit output depth is adequate for your image, it will not bother creating a 16-bit output. And so on...
If you want to force ImageMagick to do something different, you have a number of options.
If you want to force true-colour, or a palettised (indexed) output file, you can do this:
convert input.png -type palette output.png # Force palettised (indexed) output
convert input.png -type truecolor output.png # Force true colour output
If you want to force 8-bit or 16-bit, you can do this:
convert input.png -depth 8 output.png # Force 8-bit output
convert input.png -depth 16 output.png # Force 16-bit (per channel) output
If you want to force an alpha/transparency channel, you can do:
convert input.tif -type TrueColorAlpha output.png # Force a true color output with transparency
And you can combine these too. If you want to see the type options, use this command:
identify -list type
Bilevel
ColorSeparation
ColorSeparationAlpha
ColorSeparationMatte
Grayscale
GrayscaleAlpha
GrayscaleMatte
Optimize
Palette
PaletteBilevelAlpha
PaletteBilevelMatte
PaletteAlpha
PaletteMatte
TrueColorAlpha
TrueColorMatte
TrueColor
Furthermore, specifically in the case of PNG files, you can also force the output by specifying the PNG type in capitals, followed by a colon in front of the output filename, thus:
convert input.tif PNG64:output.png # Force 64-bit RGBA (3 channels # 16-bits each, plus alpha)
convert input.tif PNG32:output.png # Force 32-bit RGBA (3 channels # 8-bits each, plus alpha)
convert input.tif PNG48:output.png # Force 48-bit output (3 channels # 16-bits each, no alpha)
convert input.tif PNG24:output.png # Force 24-bit output (3 channels # 8-bits each, no alpha)
So the short answer is
convert input.tif PNG64:output.png
or
convert input.tif -depth 16 -type TrueColorAlpha output.png
Beware though, ImageMagick will override the second version if no alpha channel is present in your input image, whereas it will not do that if you use PNG64:.
The source is an RGBA PNG image (color_type=6 and bit_depth=8).
I need an image with indexed color and 2 palette items (color_type=3, bit_depth=1).
I tried with ImageMagick, but was able to reach only 1bit grayscale image (color_type=0, bit_depth=1) or 2bit indexed color image (color_type=3, bit_depth=2) in which only 2 colors are in use.
According to the PNG specification such image is possible, but how to create it?
Here is an image I am trying to convert:
The result of "convert input.png -type palette -depth 1 output.png":
The result of "convert input.png -type palette -depth 1 -colors 2 output.png"
Both results have bit_depth=2, but the second one uses only 2 colors of 4 possible.
Use one of the following 3, ordered from least to most ancillary tags in the output file:
convert -colors 2 -define png:include-chunk=none -verbose input.png output.png
convert -colors 2 -define png:exclude-chunk=bkgd -verbose input.png output.png
convert -colors 2 -background #000000 -verbose input.png output.png
The root of this problem is that ImageMagick by default tags the image with a white background color (bKGD) PNG chunk (unnecessarily I'd say), and then adds this color to the palette if it's not already there, even if the image has no pixels of that color. Your particular image doesn't have white after converting to 2-color, so the unneeded background color tag becomes a 3rd color and it can no longer be saved as a 1-bit indexed color image. See also this from the author of IM.
The reason others have failed to reproduce the problem is probably that they've tested with images where one of the 2 colors happened to be white.
The 1st option with -define png:include-chunk=none avoids the problem by not outputting any ancillary PNG chunks at all (e.g. bKGD, gAMA, cHRM, tEXt, tIME). Like pngcrush -rem alla. I'd prefer this for a less cluttered file (without it IM will add a few of these even if they weren't in the input file). Note: There's also the simple -strip option which should avoid most of these, but as of v6.9.3 it won't cut bKGD due to a bug.
The 2nd with -define png:exclude-chunk=bkgd removes only the offending background chunk.
The 3rd option with -background #000000 retains all ancillary PNG chunks including bKGD but sets it black, one of the 2 colors present in your image, so it can still be 1-bit. Adjust the color for an image with neither white nor black in it.
Note that for all these I'm including the -verbose switch. Not overly verbose; just goes from zero to two lines of status output where you'll notice a "2c" if the image stayed 2-color or a "3c" if not. It will also tell you if the palette reduction was lossy or not. It also outputs "8-bit sRGB" for most images, even paletted ones with fewer than 8 bits-per-pixel; that's not a bug as in your comment to another answer #johnfound, this refers not to the bits-per-pixel but to the bits-per-color component. It can be more than 8-bit for (rare) deep color images.
convert input.png -background white -type palette -depth 1 -colors 2 output.png
works for me.
(Why -depth=1 is not enough? No idea.)
BTW, the tweakpng tool is useful for checking this kind of things.
Update: if the images have transparency, you might play safer by removing it explicitly:
convert input.png -background white -flatten -type palette -depth 1 -colors 2 output.png
(You can replace white for your preference)
I think the command you need is this:
convert input.png -type palette -depth 1 output.png
If not, please post your input image and say how/where you find the color_type and bit_depth fields you refer to.
Exiftool tells me this:
ExifTool Version Number : 9.76
File Name : output.png
Directory : .
File Size : 2.3 kB
File Modification Date/Time : 2015:01:10 19:20:33+00:00
File Access Date/Time : 2015:01:10 19:21:46+00:00
File Inode Change Date/Time : 2015:01:10 19:20:33+00:00
File Permissions : rw-r--r--
File Type : PNG
MIME Type : image/png
Image Width : 640
Image Height : 427
Bit Depth : 1
Color Type : Grayscale
Compression : Deflate/Inflate
Filter : Adaptive
Interlace : Noninterlaced
Gamma : 2.2
Background Color : 1
Datecreate : 2015-01-10T10:21:30+00:00
Datemodify : 2015-01-10T10:21:30+00:00
Image Size : 640x427
ImageMagick identify tells me this:
Image: output.png
Format: PNG (Portable Network Graphics)
Mime type: image/png
Class: PseudoClass
Geometry: 640x427+0+0
Units: Undefined
Type: Bilevel
Base type: Bilevel
Endianess: Undefined
Colorspace: Gray
Depth: 8/1-bit
Channel depth:
gray: 1-bit
Channel statistics:
Pixels: 273280
Gray:
min: 0 (0)
max: 255 (1)
mean: 1.90168 (0.00745755)
standard deviation: 21.9388 (0.0860345)
kurtosis: 129.1
skewness: 11.4499
Colors: 2
Histogram:
271242: ( 0, 0, 0) #000000 gray(0)
2038: (255,255,255) #FFFFFF gray(255)
Colormap entries: 2
Colormap:
0: ( 0, 0, 0) #000000 gray(0)
1: (255,255,255) #FFFFFF gray(255)
Rendering intent: Undefined
Gamma: 0.45455
Background color: gray(255)
Border color: gray(223)
Matte color: gray(189)
Transparent color: gray(0)
Interlace: None
Intensity: Undefined
Compose: Over
Page geometry: 640x427+0+0
Dispose: Undefined
Iterations: 0
Compression: Zip
Orientation: Undefined
Properties:
date:create: 2015-01-10T19:20:33+00:00
date:modify: 2015-01-10T19:20:33+00:00
png:bKGD: chunk was found (see Background color, above)
png:gAMA: gamma=0.45455 (See Gamma, above)
png:IHDR.bit-depth-orig: 1
png:IHDR.bit_depth: 1
png:IHDR.color-type-orig: 0
png:IHDR.color_type: 0 (Grayscale)
png:IHDR.interlace_method: 0 (Not interlaced)
png:IHDR.width,height: 640, 427
png:text: 2 tEXt/zTXt/iTXt chunks were found
signature: 3e08d7fea7bc7aeb0659ac2e2696084083d35ce30b0e3075dc561ad94259eaec
Artifacts:
filename: output.png
verbose: true
Tainted: True
Filesize: 2.33KB
Number pixels: 273K
Pixels per second: 27.33MB
User time: 0.000u
Elapsed time: 0:01.009
Version: ImageMagick 6.8.9-8 Q16 x86_64 2014-11-10 http://www.imagemagick.org
I need to convert from png to png.
I am using ImageMagick 6.8.7-7 on Mac OS X to decrease the dimension of my png.
Here is an exact example : start.png : 20866 × 8957 = 6.6 MB
start.png is a detailed floor plan just black and white
convert start.png -resize 16384x7033 out.png
Result is out.png 16384 × 7033 = 36.9 MB
(even convert start.png -resize 16384x7033 out.jpg => out.jpg 22.7MB)
If I apply "pngquant" to out.png I can reduce to 15MB
Why does this increase happen?
I am looking for a option on convert which will not increase the size of out.png?
EDIT
Maybe it helps if I provide more infos...
I executed "identify -verbose" on both files and got following output:
Image: start.png
Format: PNG (Portable Network Graphics)
Mime type: image/png
Class: DirectClass
Geometry: 20866x8957+0+0
Resolution: 98.43x98.43
Print size: 211.988x90.9987
Units: PixelsPerCentimeter
Type: Palette
Endianess: Undefined
Colorspace: sRGB
Depth: 8-bit
Channel depth:
Compression: Zip
Orientation: Undefined
Properties:
date:create: 2014-01-19T09:06:05+01:00
date:modify: 2014-01-17T11:48:05+01:00
png:iCCP: chunk was found
png:IHDR.bit-depth-orig: 8
png:IHDR.bit_depth: 8
png:IHDR.color-type-orig: 2
png:IHDR.color_type: 2 (Truecolor)
png:IHDR.interlace_method: 0 (Not interlaced)
png:IHDR.width,height: 20866, 8957
png:pHYs: x_res=9843, y_res=9843, units=1`
Profiles:
Profile-icc: 2576 bytes
Artifacts:
filename: start.png
verbose: true
Tainted: False
Filesize: 6.603MB
Number pixels: 186.9M
Pixels per second: 41.63MB
User time: 4.480u
Elapsed time: 0:05.490
**OUT.png
Image: out.png
Format: PNG (Portable Network Graphics)
Mime type: image/png
Class: DirectClass
Geometry: 16384x7033+0+0
Resolution: 98.43x98.43
Print size: 166.453x71.4518
Units: PixelsPerCentimeter
Type: TrueColor
Endianess: Undefined
Colorspace: sRGB
Depth: 8-bit
Compression: Zip
Orientation: Undefined
Properties:
date:create: 2014-01-19T09:55:41+01:00
date:modify: 2014-01-19T09:55:41+01:00
png:bKGD: chunk was found (see Background color, above)
png:cHRM: chunk was found (see Chromaticity, above)
png:iCCP: chunk was found
png:IHDR.bit-depth-orig: 8
png:IHDR.bit_depth: 8
png:IHDR.color-type-orig: 2
png:IHDR.color_type: 2 (Truecolor)
png:IHDR.interlace_method: 0 (Not interlaced)
png:IHDR.width,height: 16384, 7033
png:pHYs: x_res=9843, y_res=9843, units=1
png:text: 3 tEXt/zTXt/iTXt chunks were found
Profiles:
Profile-icc: 2576 bytes
Artifacts:
filename: out.png
verbose: true
Tainted: False
Filesize: 36.89MB
Number pixels: 115.2M
Pixels per second: 38.54MB
User time: 2.980u
Elapsed time: 0:03.990
Version: ImageMagick 6.8.7-7 Q16 x86_6*
The reason the filesize increases is that your resize operation increases the number of colors. You could replace "resize WxH" with "-sample WxH" to only use the existing (black and white) colors.
If you're using ImageMagick, you might as well remove the ICC profile too, with "-define png:exclude-chunk=iCCP", because it's not of much use in a black-and-white image. This option isn't yet available in GraphicsMagick.