android version upgrade to 5.x, I got a png image through screenshot.
when I use imagemagick to resize it, I got an error like this
identify: Extra compressed data. `a.png' # warning/png.c/MagickPNGWarningHandler/1777.
identify: Extra compression data. `a.png' # warning/png.c/MagickPNGWarningHandler/1777.
convert: Extra compressed data. `a.png' # warning/png.c/MagickPNGWarningHandler/1777.
convert: Extra compression data. `a.png' # warning/png.c/MagickPNGWarningHandler/1777.
use pngcheck info:
File: a.png (251221 bytes)
chunk IHDR at offset 0x0000c, length 13
1440 x 2560 image, 24-bit RGB, non-interlaced
chunk sBIT at offset 0x00025, length 3
red = 8 = 0x08, green = 8 = 0x08, blue = 8 = 0x08
chunk IDAT at offset 0x00034, length 251149
zlib: deflated, 32K window, maximum compression
chunk IEND at offset 0x3d54d, length 0
No errors detected in a.png (4 chunks, 97.7% compression).
My soft version:
ImageMagick 6.7.9-0
PNG* PNG rw- Portable Network Graphics (libpng 1.2.52)
See http://www.libpng.org/ for details about the PNG format.
PNG24* PNG rw- opaque 24-bit RGB (zlib 1.2.8,1.2.1.2)
I tryed ImageMagick-6.9.1-6 and libpng-1.6.17 zlib-1.2.8, all are newest version, but got error yet
please try this png image , and help me...
http://pan.baidu.com/s/1mg3mkCo
thanks
Add the option -quiet to your convert or identify command so you don't get an error generated.
"Extra compressed data" is just a warning. You may ignore it.
The result of your "convert" operation should be OK; ImageMagick won't propagate the extra data.
Note that "pngcheck" doesn't decompress the IDAT chunks so it won't report about the extra data that is evidently due to a bug in the screenshot application.
Related
I am using a Nikon D5200. I intend to do some image processing on the raw images shot with the camera. But I am encountering a problem when I read the raw images using GNU Octave. Rather than giving bit depth of 16 (since the .NEF are shot at 14-bit depth), the result is just a 8-bit array. What might be the problem?
imfinfo("/media/karthikeyan/3434-3531/DCIM/100D5200/DSC_1094.NEF")
ans =
scalar structure containing the fields:
Filename = /media/karthikeyan/3434-3531/DCIM/100D5200/DSC_1094.NEF
FileModDate = 10-Oct-2016 18:10:02
FileSize = 26735420
Format = DCRAW
FormatVersion =
Width = 6036
Height = 4020
BitDepth = 8
ColorType = truecolor
The result from exiftool is as follows:
exiftool DSC_1094.NEF | grep -i bit
Bits Per Sample : 14
I am using Ubuntu 14.04, Octave 4.0.3.
I have some images whose type is PaletteAlpha and which have to be TrueColorAlpha. I am trying to use the command
convert testein -type TrueColorAlpha testeou
to do this conversion but the result is an image which still has Type: PaletteAlpha. Is this behaviour expected? How can I transform from one type to the other?
I have also tried things such as PNG:testeou but with no results.
My IM version is 6.7.8-9.
The PNG32: prefix forces the output PNG to be RGBA:
convert logo: -transparent white png32:logot32
identify -verbose logot32 | grep Type
Type: PaletteAlpha
pngcheck logot32
OK: logot32 (640x480, 32-bit RGB+alpha, non-interlaced, 94.1%).
"identify" reports the "Type" of the image after it has been read in. In this case, it is an image with transparency and fewer than 256 colors, so it's reported as PaletteAlpha.
"pngcheck" reports what's actually stored in the PNG file, which is RGBA.
In fact, "identify" also gives more information about the PNG file. Near the end of the "identify -verbose" output can be found:
Properties:
...
png:IHDR.bit_depth : 8
png:IHDR.color_type : 6 (RGBA)
png:IHDR.interlace_method: 0 (Not interlaced)
png:IHDR.width,height : 640, 480
...
Version: ImageMagick 6.7.8-9 2015-06-01 Q16 http://www.imagemagick.org
I'm trying to convert a 16 bit greyscale PNG to a raw file. The image size is 640*480.
First, identify:
$ identify image.png
image.png PNG 640x480 640x480+0+0 16-bit PseudoClass 65536c 299KB 0.000u 0:00.000
I'm expecting the result file to be 640*480*2 bytes in size.
Attempt 1:
$ convert image.png -depth 16 image.raw
This gives a file size of 330805 bytes. Its first 16 bytes look like:
0x00000000: 89504E47 0D0A1A0A 0000000D 49484452 .PNG........IHDR
Attempt 2:
$ convert image.png -depth 16 image.rgb
This gives a file size of 1843200 bytes, which is 640*480*2*3.
I'm running imagemagick version 6.7.7-10 on Ubuntu 14.04.
Any ideas?
Updated Answer
It occurred to me since answering you, that there is a simpler method of doing what you want, that takes advantage of ImageMagick's little-used stream tool, to stream raw pixel data around.
In effect, you can use this command
stream -map r -storage-type short image.png image.raw
which will read the Red channel (-map r), which is the same as the Green and Blue channels if your image is greyscale, and write it out as unsigned 16-bit shorts (-storage-type short) to the output file image.raw.
This is cleaner than my original answer - though should give identical results.
Original Answer
If you write an RGB raw file, you will get 3 channels - R, G and B. Try writing a PGM (Portable Greymap) like this...
convert image.png -depth 16 pgm:-
P5
640 480
65535
<binary data> < binary data>
The PGM format is detailed here, but suffice to say that there is header with a P followed by a digit describing the actual subtype, then a width and height and then a MAX VALUE that describes the range of the pixel intensities. In your case, the MAX VALUE is 65535 rather than 255 because your data are 16-bit.
You can the strip the header like this:
convert image.png -depth 16 pgm:- | tail -c 614400 > file.raw
If you are converting lots of files of different sizes and dislike the hard-coded 614400, and are using bash, you can get ImageMagick to tell you the size (height * width * 2 bytes/pixel) and use that like this:
bytes=$(identify -format "%[fx:h*w*2]" image.png)
convert image.png -depth 16 pgm:- | tail -c $bytes > file.raw
gray might be the format you want:
convert image.png -depth 16 image.gray
This command stores each pixel in 2 bytes and nothing else in the file.
Here I provide a minimal synthetic example: https://superuser.com/questions/294270/how-to-view-raw-binary-data-as-an-image-with-given-width-and-height/978432#978432
.raw is not really a "pixel only" format: it does contain some metadata: https://en.wikipedia.org/wiki/Raw_image_format#File_contents
I have 100 PNG-files and each of them is 8250x4090 big. I need to append them with Imagemagick to one big PNG-file (82500 x 40900) so that I have 10 rows and 10 columns . I know how the code must look like but I get the errors: convert.exe: unable to extend cache
`C:\Row_345.png': No space left on device # error/cache.c/OpenPixelCache/3689.
convert.exe: Memory allocation failed `C:\Row_345.png' # error/png.c/WriteOnePNGImage/8725.
First question: How much space is needed (approximately)? I have 8 GB of Ram and 30 GB free SSD and it wasn't enough. The pictures have polygons and lines in up to 5 different colors. The biggest PNG is 300 KB)
Second question: Is there a way how to make it more clever so that it won't use that much space?
ImageMagick needs 8 bytes per pixel if you are using a Q16 build. A Q8 build only needs 4 bytes per pixel.
82500 * 40900 * 8 = about 27Gbytes
82500 * 40900 * 4 = about 13.5 Gbytes
The size of the PNG is irrelevant; ImageMagick stores them uncompressed.
Possibly ImageMagick is trying to hold two copies -- your 100 small images plus the large result. It may be that you'll have enough memory plus disk to run your conversion with ImageMagick-Q8.
Try doing just a single row of 10 at a time, ten times - so you get 10 rows of 10. Then do row1 plus row2. Then rows 1&2 plus row 3.
convert 1.png 2.png 3.png ... +append row1.png
convert 11.png 12.png 13.png ... +append row2.png
...
convert 91.png 92.png 93.png ... +append row10.png
Then
convert row1.png row2.png -append row1and2.png
You can add -debug cache to your ImageMagick convert command like this:
convert -debug cache 1.png 2.png 3.png ... +append row1.png
You can also look at your resource settings as to what is available to ImageMagick like this:
identify -list resource
File Area Memory Map Disk Thread Time
-------------------------------------------------------------------------------
768 1.0386GB 3.8692GiB 7.7384GiB unlimited 4 unlimited
And increase resources like this:
convert -limit memory 32MiB ...
In this post, i was wondering why my png files were badly displayed on retina displays.
I finaly found that the problem came from the PNG file itself: when I open it and save it again with photoshop or something else, the problem disapear.
As this post proposed, I used sips command to see what exactly were formed my PNG file. I have the original-image.png (with the glitch) and the photoshoped-image.png
The command
sips original-image.png -g all
Gives me
pixelWidth: 256
pixelHeight: 256
typeIdentifier: public.png
format: png
formatOptions: default
dpiWidth: 72.000
dpiHeight: 72.000
samplesPerPixel: 3
bitsPerSample: 8
hasAlpha: no
space: RGB
And
sips photoshoped-image.png -g all
Gives me
pixelWidth: 256
pixelHeight: 256
typeIdentifier: public.png
format: png
formatOptions: default
dpiWidth: 72.000
dpiHeight: 72.000
samplesPerPixel: 4
bitsPerSample: 8
hasAlpha: yes
space: RGB
profile: HD 709-A
So 3 differences :
samplePerPixel
hasAlpha
the photoshoped file has a profile.
But these properies are read-only in sips and I wonder how can I change them to understand exactly where the bug comes from.
Any idea ?
So using sips you can output a different file. Take the photoshop file and start modifying it. First remove the profile, then remove the alpa channel (which will affect the first two variables).
Its quite possible that this image works. PNG has many options, and the original image may have some other feature not visible using these tools. Photoshop is obviously re-writing the image completely, using the RGB values as the only common attribute between the files.
I suspect that when you do the above, that image will work too. There is just something odd about the originals.
In any case, you make it easier on iOS if you use pngs with an alpha channel, as it will convert them to have one if the base image does not have one.
On some files, this works:
sips -s format png '/Volumes/HD/Optimized PNG/TXT - Section Depth copy.png' --out '/Volumes/HD/Optimized PNG/TXT - Section Depth copy-.PNG'
/Volumes/HD/Optimized PNG/TXT - Section Depth copy.png
/Volumes/HD/Optimized PNG/TXT - Section Depth copy-.PNG
mis-bhayward61p-swk:~ zav$
But also, sometimes it doesn't:
sips -s format png --setProperty hasAlpha 0 '/Volumes/HD/Optimized PNG/Subsection copy 2/Section Depth Text.png' --out '/Volumes/HD/Optimized PNG/Subsection copy 2/Section Depth Text-.PNG'
/Volumes/HD/Optimized PNG/Subsection copy 2/Section Depth Text.png
Error: Cannot do --setProperty hasAlpha on file
/Volumes/HD/Optimized PNG/Subsection copy 2/Section Depth Text-.PNG
mis-bhayward61p-swk:~ zav$
Hope this gets you a little farther.