I am seeing the following image in a paper:
However, when I download the associated dataset with the paper, the images are like this:
How can I make the almost black images in the dataset looking like the one in the paper?
link to dataset: http://www.cs.bu.edu/~betke/research/HRMF2/
link to paper: http://people.bu.edu/breslav/084.pdf
The contents of this dataset is saved as 16 png data. But ordinary display has only 8bit dynamic range. So we cannot display them without windowing. Please try to use ImageJ, it can map 16bit data into visible 8bit data.
https://imagej.nih.gov/ij/index.html
It can show as following.
As the other answers rightly say, the images are in 16-bit PNG format. You can convert one to a conventionally scaled, viewable JPEG with ImageMagick which is installed on most Linux distros and is available for macOS and Windows.
So, in Terminal:
magick 183.png -auto-level 183.jpg
If you would like to convert all 800 images to JPEGs in one go, you can use ImageMagick's mogrify like this:
magick mogrify -format JPEG -auto-level *png
Note that if your ImageMagick is the older v6 (as opposed to the v7 commands I used) the two commands become:
convert 183.png -auto-level 183.jpg
mogrify -format JPEG -auto-level *png
The images in this dataset have high dynamic range of 16-bits per pixel. Image viewer you are using is mapping 16-bit pixels to 8-bit ones, in order to display them (most displays can only effectively handle 8 or 10 bits of brightness). Most image viewers will just truncate the least significant 8 bits, which in your case produces nearly black image. To get better results, use ImageJ (Fiji distribution is the easiest way to get started), which displays this:
Related
I have a ps image that I want to convert to a gif image with horizontal by vertical dimensions of 900 and 800 respectively. I have tried to use the command:
convert panel.gs -resize x800 y900 panel.gif
or also:
convert panel.gs -resize 900x800 panel.gif
Can you help me to tweak the convert commands so I can get the desired results?
.gs is not a valid suffix. Did you mean .ps?
Imagemagick will need ghostscript as a delegate. You did not say what was wrong nor what platform or what version of Imagemagick.
If the image does not have the same aspect ratio as the final dimensions you want, you will either 1) need to distort it to fit using !, 2) resize it and then extend to the size you want filling with background color, or 3) resize it with ^ and crop it to the size you want.
convert panel.ps -resize "900x800!" panel.gif
convert panel.ps -resize 900x800 -gravity center -background white -extent 900x800 panel.gif
convert panel.ps -resize "900x800^" -gravity center -extent 900x800 panel.gif
Well, firstly you haven't actually said what's wrong with the two commands that you have tried already.....
Your PostScript program probably does not contain an 'image' as such, PostScript is not a bitmap format its a programming language.
You can use Ghostscript to render the PostScript to an image, and then use ImageMagick to resize that image, possibly you can combine these two steps, or just perform a single conversion, it depends on what exactly you want to happen, which isn't clear.
If (for example) your PostScript program requests a media size of 9 inches by 8 then you can create a bitmap image by simply setting the resolution to 100 dpi using -r100.
If you want the image scaled differently in each direction, then you need to set a non-square resolution. For example if the PostScript program requests media of 9 inches by 4 then you need to set the resolution to 100x200 in order to get an image exactly 900 x 800 pixels. You would use -r100x200 for this.
The alternative, from a PostScript point of view, is to set the media size to a given
value in pixels (using -g900x800) and set -dDFIXEDMEDIA which prevents the PostScript program from changing it. You can then use -dFitPage which will have Ghostscript scale the content to fit the page. However it will scale the content equally in both directions, which may leave white space around the edge.
Now since Ghostscritp doesn't write GIF directly you'll need to load whatever bitmap format you select into IM in order to write it out as a GIF, so perhaps the simplest solution is just to use Ghostscript to render the PostScript to a defined resolution (eg 100 dpi) and then load that image into IM and rescale it there.
Since IM (and therefore convert) use Ghostscript to process PostScript programs, that's what's happening now so it isn't obvious to me what your problem is.
I'm trying to batch convert PDF's to PNG's. Previously, this was always done manually through GIMP by importing a PDF, then converting it to PNG.
With the script that I wrote, this should all be done automatically. But for some reason, the image quality I get from using
convert \
-density 300 \
-adaptive-resize 2048 \
-define png:compression-level=9 \
"File1"
"File2"
Doesn't have the same "quality" compared to doing it via GIMP. See the image below for the difference in image quality.
In GIMP, I don't change much to the image. When I import the PDF, I change the resolution to 2048 pixels. When I convert and export it to PNG, I use all the default values GIMP offers, nothing fancy.
Changing the density to a higher or lower value doesn't do anything to the image. Also changing adaptive-resizing to normal resizing doesn't do much.
In the example image, both pictures are 2048 pixels wide. As you can see the lower image has a lot thicker/blurrier lines.
Example image comparison:
So, I have found a way around my problem.
Increasing the PPI kind of helped but still not as much as I would have liked it to.
Eventually I added this:
-channel A -fx "p*(p>0.2?22:0)"
Just some simple piece of code I found somewhere around here. It checks for the Alpha levels in the picture and if it's below a certain threshold it will just remove or "make the pixel" transparent. If it's over the threshold it will just boost the pixel to maximum visibility. Combined with the high PPI I dont get any "half pixels" anymore.
When working with JPEG image properties (resolution, sampling, etc.) and you export the final product are you ALWAYS double dipping into 'jpegification'?
From my understanding when you load a JPEG image into an image manipulation tool (GIMP, Photoshop, ImageMagick, etc.) it goes like so:
Import JPEG
Decode JPEG into easier workable format (Bitmap)
Manipulate the pixels
Export back into JPEG (REDOING JPEG QUANTIZATION AGAIN, even if you copy the original JPEG parameters it's a double dip)
Am I correct in this?
Thanks!
Any areas of the image that have changed would have to be quantized again anyway.
In theory, an application could keep the quantized values lying around then use them again. However,
That would require 3 times as much memory. The quantized values require 16 bits to store (+8 bits for the pixel value).
If you changed the sampling or quantization tables, the quantized values would have to be recalculated.
There would be very few cases where it would make sense to hang on to the quantized DCT values.
I think it depends on what you do after reading the image... but I think you can check for yourself for any particular operation and whether it has re-quantised by using this function in ImageMagick
identify -format "%#\n" image.jpg
bb1f099c2e597fdd2e7ab3d273e52ffde7229b9061154c970d23b171df3aca89
which calculates the checksum (or signature as IM calls it) of the pixels - disregarding the header information.
So, if I create a file of random noise, like this
convert -size 1000x1000 xc:gray +noise gaussian image.jpg
and get the checksum of the data, like this
identify -format "%#\n" image.jpg
84474ba583dbc224d9c1f3e9d27517e11448fcdc167d8d6a1a9340472d40a714
I can then use jhead to change the comment in the header, like this
jhead -cl "Comment" image.jpg
Modified: image.jpg
and yet the checksum remains unchanged so I would say jhead has NOT re-quantised the data.
I guess my point is that your statement that images are ALWAYS re-quantised is not 100% accurate and it depends on what you actually do to the image, and further, that I am showing a way you can readily check for yourself whether any processing has actually caused requantisation. HTH !!!
I'm really struggling trying to understand how to at least preserve if not reliably change density/resolution (not sure what to call it) when converting between file types with sampled images using ImageMagick's convert command line tool
I'm starting with a PDF file that has been scanned at either 200 or 300 dpi. I'd like to be able to convert it to TIFF and PNG for use with various OCR and QR code scanning utilities that only accept one of those formats.
The documentation at http://www.imagemagick.org/script/convert.php is "minimal" to say the least. Parameters that look like they could apply include the following:
Image Settings:
-density geometry horizontal and vertical density of the image
-sampling-factor geometry
horizontal and vertical sampling factor
Image Operators:
-resample geometry change the resolution of an image
-resize geometry resize the image
-sample geometry scale image with pixel sampling
-scale geometry scale the image
I've tried -density 200 and -density 200x200, both with no avail. Conversions to both tiff and png seem to take place at 72dpi independent of the source resolution.
I'd like to know what to use for this particular situation (i.e. preserving the resolution), but I'd also like to understand where I'm supposed to be able to get more documentation, including definition of terms, format of arguments, etc.
Recently, I read an interesting optimization technique to optimize transparent PNG images.
The idea was to split a transparent PNG image into 2 parts : PNG 8 bit with color information and PNG 24 with transparency, and to merge it on the client side. It will drastically reduce the size of the image. In the article example made with Photoshop, but I'm pretty sure, we could make it automatically with imagemagick.
So, the question is : how to do split a PNG image with imagemagick in such way ?
The article talks about "dirty transparency" which means the colour values of transparent pixels, although not visible, are retained in the image - they are just made invisible by the alpha layer.
These values, because they continue to contain the colour information, prevent the PNG optimiser from encoding them efficiently. You can achieve what the article suggests in this respect within ImageMagick by using:
convert image.png ... -alpha background result.png
That will make all transparent pixels have the same colour (your background colour) and then the PNG encoder will be be able to optimise them more readily since the values repeat over and over again.
See last part of this answer.