I use the following minimal PostScript file:
%!PS-Adobe-2.0
%%BoundingBox: 0 0 100 100
0 0 moveto 100 100 rlineto stroke
showpage
This draws a line from (0,0) to (100,100) in a 100x100 box.
I then convert this file minimal.ps to a PNG with this command line, borrowed from GhostScript's documentation:
gs -sDEVICE=pngmono -o minimal.png minimal.ps
With GPL Ghostscript 9.53.3 (current Debian stable) and 9.27 (oldstable) the resulting PNG file has the following dimensions:
> identify minimal.png
minimal.png PNG 612x792 612x792+0+0 8-bit Gray 2c 2994B 0.000u 0:00.000
Both width and height extend far beyond the original BoundingBox, and they are not even equal.
The PNG's dimensions are the same if the output device is pnggray, pngalpha, etc.
The dimensions are also the same if, in the PostScript code, 100 is replaced by 10 or by 10000.
How can I tell GhostScript to create a PNG file whose dimensions automatically fit the PostScript file's BoundingBox?
Related
I don't understand :
if we considerate the value 00001111 (15) is a byte and a RGB pixel (220,180,155) it's 3 bytes whatever the values of the pixel.
so why when i reduce the values of my pixels (with bitshift operation or whatever) the size of
my image is not = pixel numbers x 3. when i say "pixel numbers" i mean "pixel numbers bigger than fully black".
how the mechanism works ? is it counted in bits and then divided by eight as an average ?
if i have a 3MB picture and i do a bitshift (factor 2 on each 3 RGB channel) i found a 300 KB picture.
Don't tell me 90% of my pixels turned fully black.
Thanks.
If you shift all the pixel values right by 2 places, you will have around 1/4 as many shades of red as before, and around 1/4 as many greens and likewise for blues. That means overall you will have vastly fewer colours. That means your image may well have fewer than 256 colours which means it can be palettised. It also means it is likely to compress better because there will be more repetition of fewer unique sequences.
You can check if your image is palettised in several ways:
open it with PIL and check if image.mode contains a P
run exiftool on it and check if Colour Type is Palette
run ImageMagick on it with magick identify -verbose YOURIMAGE
You can count the number of unique colours in your image with ImageMagick using:
magick identify -format %k YOURIMAGE
Or you can do it in Python with the last part (entitled "Update") of this answer.
I have an image stored as BytesIO of Pillow and I need to save it to a file with some header information (containing textual attributes) that I need to add specific to my problem. I need the bytes to be represented according to some image compression format. Would that be possible? If yes, how it can be done?
I also need to store more than one image in the file.
Storing more than one image in a file is problematic for PNG, JPEG and the most of the common formats. One option for that is TIFF - not sure if that works for you?
Here's how you can store some additional text in a PNG at least:
#!/usr/bin/env python3
from PIL.PngImagePlugin import Image, PngInfo
# Create empty metadata and add a couple of text strings
metadata = PngInfo()
metadata.add_text("Key1:","Value1")
metadata.add_text("Key2:","Value2")
# Create red image and save with metadata embedded
im = Image.new('RGB',(64,64),'red')
im.save("result.png", pnginfo=metadata)
If you check that with pngcheck you will see:
pngcheck -7v result.png
Sample Output
File: result.png (200 bytes)
chunk IHDR at offset 0x0000c, length 13
64 x 64 image, 24-bit RGB, non-interlaced
chunk tEXt at offset 0x00025, length 12, keyword: Key1:
Value1
chunk tEXt at offset 0x0003d, length 12, keyword: Key2:
Value2
chunk IDAT at offset 0x00055, length 95
zlib: deflated, 32K window, default compression
chunk IEND at offset 0x000c0, length 0
No errors detected in result.png (5 chunks, 98.4% compression).
Here's how to save 3 images and a comment in a single TIFF file:
from PIL import Image
from PIL.TiffImagePlugin import ImageFileDirectory_v2, TiffTags
# Create a structure to hold meta-data
ifd = ImageFileDirectory_v2()
ifd[270] = 'Some Funky Comment'
ifd.tagtype[270] = TiffTags.ASCII
# Create red image and save with metadata embedded
im1 = Image.new('RGB',(50,50),'red')
im2 = Image.new('RGB',(64,64),'green')
im3 = Image.new('RGB',(80,80),'blue')
im1.save("result.tif", append_images[im2,im3], save_all=True, tiffinfo=ifd)
And check that with:
tiffinfo -v result.tif
Sample Output
TIFF Directory at offset 0x8 (8)
Image Width: 50 Image Length: 50
Bits/Sample: 8
Compression Scheme: None
Photometric Interpretation: RGB color
Samples/Pixel: 3
Rows/Strip: 50
Planar Configuration: single image plane
ImageDescription: Some Funky Comment
TIFF Directory at offset 0x1e08 (7688)
Image Width: 64 Image Length: 64
Bits/Sample: 8
Compression Scheme: None
Photometric Interpretation: RGB color
Samples/Pixel: 3
Rows/Strip: 64
Planar Configuration: single image plane
ImageDescription: Some Funky Comment
TIFF Directory at offset 0x4eb8 (20152)
Image Width: 80 Image Length: 80
Bits/Sample: 8
Compression Scheme: None
Photometric Interpretation: RGB color
Samples/Pixel: 3
Rows/Strip: 80
Planar Configuration: single image plane
ImageDescription: Some Funky Comment
You can then extract the images on the command-line with ImageMagick like this.
To extract first image:
magick result.tif[0] first.png
To extract last image:
magick result.tif[-1] last.png
To extract all three images:
magick result.tif image-%d.png
Result
-rw-r--r-- 1 mark staff 457 21 Jan 08:11 image-0.png
-rw-r--r-- 1 mark staff 458 21 Jan 08:11 image-1.png
-rw-r--r-- 1 mark staff 460 21 Jan 08:11 image-2.png
Note: Use convert in place of magick above if you are running v6 ImageMagick.
Keywords: Python, PIL, image processing, multiple images, TIF, comment, tiffinfo, IFD, PNG tEXt.
Unable to convert a JPEG image into a 300 DPI PNG image using ImageMagick.
After conversion the PNG image is 72 DPI only. I'm using ImageMagick 6.9.0-0 Q16 x86 and Ghostscript v9.15.
Below is the line I use in my Perl script:
system("\"$imagemagick\" -set units PixelsPerInch -density 300 \"$jpg\" \"$png\"");
Adjusting the units & density will not alter the underlining image data, but updates meta info for rendering libraries. Important for vector to raster, but not very useful for raster to raster. To adjust the DPI of an image, use the -resample operation.
convert source.jpg -resample 300 out.png
You verify the DPI resolution with the following...
identify -format "%[resolution.x] %[resolution.y]\n" out.png
I'm wondering where the 72dpi is coming from. Assuming you are using X and some kind of Unix, ImageMagick defaults to using the screen resolution (72 dpi). I'm not sure what it does under OSX/XQuartz but it's likely similar. Is your screen resolution set to 72dpi (!?).
I'm with #emcconville #ikegami - just do this straight from ImageMagick on the commandline - passing the right options to be sure.
There are image manipulation modules that you can use from perl without having to resort to system commands as well such as Imager::Transformations, Image::Magick, and GD. Here's how to convert with GD.
perl -MGD -E 'my $imgjpg = GD::Image->newFromJpeg("img.jpg");
open my $imgpng, ">", "img.png" or die; print $imgpng $imgjpg->png();'
With most image manipulation packages the original resolution show be maintained during conversion - though some (including GD) will default to lower color depths (8 bit) unless passed a Truecolor flag.
e.g. GD::Image->newFromJpeg("img.jpg", 1);
I'm trying to write a TIFF image with RMagick that tesseract can process. Tesseract objects if bits per pixel is > 32 or samples per pixel is other than 1, 3 or 4.
With the defaults, Image.write generates 3 (RGB) samples plus 1 alpha channel at 16-bits per sample for a total of 64 bits per pixel, violating the first constraint.
If I set the colorspace to GRAYColorspace as follows, it still outputs the alpha channel, giving two samples per pixel, violating the second constraint.
Image.write('image.tif) {self.colorspace = GRAYColorspace}
Per the RMagick documentation, the alpha channel is ignored on method operations unless specified, but even if I do self.channel(GREYChannel), the alpha channel is still output.
I know I can run convert on the file afterwards, but I'd like to find a solution that avoids that.
Here is the tiffinfo output for the file currently generated:
TIFF Directory at offset 0x9c48 (40008)
Image Width: 100 Image Length: 100
Bits/Sample: 16
Compression Scheme: None
Photometric Interpretation: min-is-black
Extra Samples: 1<unassoc-alpha>
FillOrder: msb-to-lsb
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 2
Rows/Strip: 20
Planar Configuration: single image plane
Page Number: 0-1
DocumentName: image-gray-colorspace.tif
White Point: 0.3127-0.329
PrimaryChromaticities: 0.640000,0.330000,0.300000,0.600000,0.150000,0.060000
In Fireworks, when you export a PNG8 file with alpha transparency, the resulting file will be something like this:
png8-fireworks.png: PNG image data, 500 x 500, 8-bit colormap, non-interlaced
If you convert a 32bit PNG using other tools (PNGOUT, Smush.it) the result looks like this:
png24-smushit.png: PNG image data, 500 x 500, 8-bit/color RGBA, non-interlaced
png8-pngout.png: PNG image data, 500 x 500, 8-bit/color RGBA, non-interlaced
What exactly is the difference? They both have alpha transparency, but the Fireworks file is 8KB while the others are 20KB. Now the Fireworks file in noticeably lower quality (namely with banding on gradients).
For some images the PNG8+alpha from Fireworks works great and has a super small file size comparatively. I just haven't been able to figure out what Fireworks is doing and how it is different than the other methods.
The PNG8 file is a very efficient format. It finds the unique colors in the image and only saves those in a small palette. The cool part is that it also saves alpha transparency in the palette with each color. (If you have three pure reds (#FF0000) in your image, but each has a different alpha value, let's say 255, 128, 65, it will save three entries in the palette.
You can also in Fireworks choose to limit the palette size to a power of 2, so you can reduce colors used for more savings. Often a 256 color image will look fine at 64 colors and save a lot of weight.
from sites of both tools:
PNGOUT:
It won't convert an image to a color type or bit depth that cannot losslessly store the image.
It won't reduce the number of colors being used in an image, or convert the colors to grayscale unless all the colors correspond to PNG grayscale values already.
Smush.it:
It is a "lossless" tool […]
Neither gives you a 256 paletted png: it's the diff between "colormap" (= palette) and "rgba" (truecolor = R of 2^8 x G of 2^8 x B of 2^8 x Alpha of 2^8, with 2^8 = 256).
Fireworks does.
PNG-8 means 8 bits per pixel, which means it can only display 256 different colours (from a pallet).
24 and 32 bits per pixel allow you to use far more colours (and hence get nice smooth gradients) but come at the cost of filesize.