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:.
Related
I created an image with convert -size 1920x1080 xc:white white.png, but it appears to have a greyscale color profile and this is undesirable.
identify -verbose shows
Colorspace: Gray
Type: Grayscale
for "normal" images, these properties don't even seem to be mentioned.
How can I change it so that the image can have color?
You can force an RGB888 image like this:
convert -size 1920x1080 xc:white PNG24:white.png
Check:
identify -verbose white.png | egrep "Colorspace:|Type:"
Colorspace: sRGB
Type: Bilevel
I'm trying to convert some small PNG images from 32-bit color mode to indexed color mode.
For color images, I ran the command convert IMGS/FLAME.png INDEXED_IMGS/FLAME.png and it converted fine. For an image that had only grayscale colors, I ran that same command (with the filename changed obviously) but I got a warning:
convert: profile 'icc': 'RGB ': RGB color space not permitted on grayscale PNG 'INDEXED_IMGS/SHADOW.png' # warning/png.c/MagickPNGWarningHandler/1748.
I ran file IMGS/*.pngand got
IMGS/FLAME.png: PNG image data, 16 x 16, 8-bit/color RGBA, non-interlaced
IMGS/SHADOW.png: PNG image data, 8 x 8, 8-bit/color RGBA, non-interlaced
which is expected; both images are in 8-bit RGBA mode (since that's the mode I created them in Photoshop). However, when I run file INDEXED_IMGS/*.png I get
INDEXED_IMGS/FLAME.png: PNG image data, 16 x 16, 4-bit colormap, non-interlaced
INDEXED_IMGS/SHADOW.png: PNG image data, 8 x 8, 8-bit grayscale, non-interlaced
The 4-bit colormap part checks out, but the grayscale part does not.
So my question is: how can I convert a grayscale image to indexed mode? What really gets me is that it starts out in RGBA mode like the color image, but for some reason it converts automatically to grayscale mode. Is there a way to prevent it from doing that?
I should add that I have a bash script that looks like this:
#!/bin/bash
for img in IMGS/*.png; do
file=$(basename $img)
convert $img INDEXED_IMGS/$file
done
so I don't wanna manually distinguish between grayscale and colored images. If there's a way to do so automatically with some command that's fine though.
Here is info about my ImageMagick tool:
Version: ImageMagick 7.0.8-42 Q16 x86_64 2019-04-24 https://imagemagick.org
Copyright: © 1999-2019 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC HDRI Modules OpenMP
Delegates (built-in): bzlib freetype heic jng jp2 jpeg lcms ltdl lzma openexr png tiff webp xml zlib
With ImageMagick, for 24-bit color, append the output with PNG8:output
convert input.png PNG8:output.png
PNG grayscale images do not support color profiles, so you get that warning. But the resulting image should be 8-bit palette.
If you have 32-bit color, then this needs more to be done. The color under the alpha channel must be one constant color and one not used elsewhere in the image. Find such a color after converting to 256 colors and set the color under the transparency to that color. For example if you have no opaque black in your image after converting to 256 colors, then set the alpha base color to black.
convert image.png +dither -colors 256 -background black -alpha background PNG8:output.png
You can get a list of unique colors from the image as follows:
convert image.png +dither -colors 256 -unique-colors txt:
Here is an example:
Make it 32-bit transparent:
convert rose.png -fuzz 20% -transparent red rose_trans32.png
identify -verbose rose_trans32.png
...
Colorspace: sRGB
Type: TrueColorAlpha
...
Convert to palette alpha:
convert rose_trans32.png -alpha off +dither -colors 256 -unique-colors txt:
List shows no black
convert rose_trans32.png +dither -colors 256 -background black -alpha background PNG8:rose_trans8.png
Or if you already know that the 32-bit version has not black, then just:
convert rose_trans32.png -background black -alpha background PNG8:rose_trans8.png
identify -verbose rose_trans8.png
...
Colorspace: sRGB
Type: PaletteAlpha
...
If you do this adding -colorspace gray, ImageMagick will still report as type grayscalealpha, since it recognizes it as a single channel image with transparency. But using EXIFTOOL, it will report 9 ColorType: 3, which is 3 = RGB Palette
NOTE: For ImageMagick 7, change convert to magick.
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 have a batch script that converts my PNG-24 (with Transparency) images to 50% and 25% size (for mobile development). Usually these images have colors in them but now I am trying to convert an image that has no colors and ImageMagick keeps changing the colorspace profile to "Gray", which messes up my image in the 3d engine I'm using (Unity).
I have tried forcing it to use type TrueColor, colorspace sRGB, and the sRGB.icc profile (the one included with OSX) but it doesn't seem to care. It still changes it to Gray.
> convert old.png -profile srgb.icc -colorspace sRGB -type TrueColor new.png
> identify *.png
old.png PNG 140x140 140x140+0+0 8-bit sRGB 3.68KB 0.000u 0:00.000
new.png PNG 140x140 140x140+0+0 8-bit sRGB 256c 2.33KB 0.000u 0:00.000
ImageMagick still identifies it as an 8-bit sRGB image but it puts "256c" after it which I'm assuming means it has reduced it down to 256 colors, which I don't want either. When I look at the image in OSX Preview.app, it says it is using the Gray color profile. The image also visually looks a lot different.
Here is the image I'm using: https://dl.dropbox.com/u/59304/old.png
There is a duplicate question here, ImageMagick Reduces Colorspace to Gray, but the answer does not work for me and I don't have enough reputation to comment on his answer, unfortunately. I imagine my case is different because I'm using PNG and not JPG.
Version: ImageMagick 6.8.0-7 2013-01-02 Q16 http://www.imagemagick.org
Features: OpenCL
edit- After reading the ImageMagick forums as specified in one of the answers, it looks like just prepending PNG32: or PNG24: to the output file solves the problem.
The proper way to keep a grayscale PNG as RGB is to use PNG24:result.png
Input:
convert lena.png -colorspace gray PNG24:lenag_rgb.png
identify -verbose lenag_rgb.png
Image: lenag_rgb.png
Format: PNG (Portable Network Graphics)
Mime type: image/png
Class: DirectClass
Geometry: 256x256+0+0
Units: Undefined
Colorspace: sRGB
Type: Grayscale
So as you see above, Colorspace is RGB while the type is Grayscale.
For other image formats such as JPG and TIFF, use -define colorspace:auto-grayscale=false along with -type truecolor.
You may pass -set colorspace:auto-grayscale off to convert to disable automatic conversion of RGB channels to a single grayscale channel.
This solution was not yet available at the time of your question, but was introduced in 2015 with version 6.9.2:
2015-07-25 6.9.2-0 Dirk Lemstra <dirk#lem.....org>
Added -set colorspace:auto-grayscale=false that will prevent automatic conversion to grayscale inside coders that support grayscale.
I'm trying to create a transparent PNG with ImageMagick. No matter the incantations to "convert", when I use identify against the image, it always says:
Depth: 8/1 bit
Channel depth:
gray: 1 bit
alpha: 1 bit
When I look at a transparent PNG found on the web, it says:
Depth: 8 bit
gray: 8 bit
alpha: 8 bit
The reason this seems to matter is that I'm using the transparent PNGs I create as a watermark within FFMPEG. When I use the PNG that ImageMagick creates, it causes the video to appear to have like a 50% gray opacity. However, when I use the PNG I found on the web, it works fine. According to identify, the only difference is the depth.
Here are some of the things I've tried:
convert -size 640x480 xc:none -depth 8 test.png
convert -size 640x480 xc:transparent -depth 8 test.png
The other thing I noticed is that Gimp shows the ImageMagick image to have a Colorspace of Grayscale, even though identify says it's RGB. The image that I found on the web, that works, shows a Colorspace of RGB in both Gimp and identify.
Any ideas?
First, about ImageMagick's 'grayscale'.
ImageMagick doesn't actually have such a colorspace. It only fakes it within RGB space, by setting all values in the R (red), G (green) and B (blue) channels to the same values. (If the three values are not the same, the image is no longer grayscale.)
Second, about your (seemingly) unsuccessful attempts to create images with 8-bit alpha channel.
This is caused by you not putting any different 'color' values into your transparent areas -- they are all plain (fully transparent).
Try this command which converts the built-in ImageMagick logo: picture:
convert \
logo: \
-bordercolor white \
-background black \
+polaroid \
polaroid.png
The output image:
will happily show your required 8-bit alpha values:
identify -verbose polaroid.png | grep -A 4 "Channel depth:"
Channel depth:
red: 8-bit
green: 8-bit
blue: 8-bit
alpha: 8-bit
Or try to convert the built-in rose: image to a semi-transparent one:
convert rose: -alpha set -channel A -fx '0.5' semitransp-rose.png
Same result: 8-bit depth for alpha channel.
To modify one of your original commands:
convert -size 640x480 xc:none -depth 8 -channel A -fx 0.5 test.png
If you identify -verbose the resulting image, you'll find the R, G and B channels to be only 1-bit depth, while the A channel is 8-bit. That's because it's actually using a value different from 0, while the other channels are all 0.