I am trying to convert a BMP from 24 bits/pixel to 16 bit/pixel Mode in ImageMagick.
convert /tmp/a/new/37.bmp -depth 5 -define bmp:format=bmp2 /tmp/a/new/37_v2_16bit.bmp
convert /tmp/a/new/37.bmp -depth 5 -define bmp:format=bmp3 /tmp/a/new/37_v3_16bit.bmp
The result has the same 8 bit per R., per G. and per B., according to output of:
identify -verbose
What am I doing wrong? How to get 16-bit color in BMP ?
Thank you!
P. S.
-depth value
depth of the image. This is the number of bits in a pixel. The only acceptable values are 8 or 16.
http://linux.math.tifr.res.in/manuals/html/convert.html
=(
Official Documentation says (no restrictions mentioned):
-depth value
depth of the image.
This the number of bits in a color sample within a pixel. Use this option to specify the depth of raw images whose depth is unknown such as GRAY, RGB, or CMYK, or to change the depth of any image after it has been read.
convert /tmp/a/new/37.bmp -colors 256 /tmp/a/new/37_256.bmp
makes the file smaller, but visually it is the same! wth?! )))))
convert /tmp/a/new/37.bmp -colors 65536 /tmp/a/new/37_64k.bmp
same size, same visual picture.
convert /tmp/a/new/37.bmp -dither None -colors 256 /tmp/a/new/37_256_nd.bmp
a bit smaller again, but it does not look like 256-colored! bug? 256 colored 800x600 BMP is ~ 800x600x1 Bytes (without headers) ~ 480 000 Bytes. But it says ~650 000 Bytes)))) funny program))
The documentation you quoted from linux.math... is pretty old (2001) and is incorrect about -depth. The "-depth 16" option does not mean 16-bit pixels (like R5G6R5 or R5G5R5A1); -depth 16 means 48-bit/pixel R16, G16, B16 or 64-bit/pixel R16, G16, B16, A16 pixels. The "Official documentation" that you quoted (2015) is correct.
ImageMagick doesn't support that kind of 16 bit/pixel formats, so you'll need to store them in an 8 bit/channel format and live with the larger filesize.
It also appears that for images with 256 or fewer colors, it will write a colormapped image with 1, 4, or 8-bit indices. You don't have to make any special request, it'll do that automatically. Use "-compress none" for uncompressed BMP's. The current ImageMagick (version 6.9.2-8) gives me the expected 480kbyte file if I start with an 800x600 image with more than 256 colors and use
convert im.bmp -colors 256 -compress none out.bmp
ImageMagick does support a 16-bit "bitfields" BMP format while reading but I don't see any indication that it can write them, and haven't tried either reading or writing such images.
It's not ImageMagick but ffmpeg, more associated with video, can create a 16bit bmp image if you are referring to the 565 format?
ffmpeg -i ffmpeg-logo.png -sws_flags neighbor -sws_dither none -pix_fmt rgb565 -y ffmpeg-logo-16bit-nodither.bmp
That intentionally disables dithering but if you want that just omit the sws parts, e.g.
ffmpeg -i ffmpeg-logo.png -pix_fmt rgb565 -y ffmpeg-logo-16bit-dithered.bmp
If your images are inherently from an rgb565 source then it should not dither them but I'd always be cautious and inspect a few closely before doing any batch conversions.
Based on the discussion in the comments it sounds like PNG would be a good format for preserving old screenshots verbatim as it uses lossless compression but maybe that's not applicable due to use with vintage software?
Related
Using ImageMagick's convert utility to convert some scanned jpg files to pbm files.
However, even if the option -quality 100 is used, the pbm's resolution still looks worse than the original scanned jpg file.
Worse, the scanned jpg file is a colored one, while the converted pbm is black and white.
Info of original jpg:
image size: 2256 × 1568 pixels
dpi: 300 pixels/inch
color model: RGB
info of the converted pbm:
image size: 2256 × 1568 pixels
dpi: 72 pixels/inch
color model: Gray
Currently, here is what I did to convert the format:
qiang#bonjour:~/scan$ convert scan000.jpg scan000.pbm
Am I missing any option to use with convert? As I mentioned earlier, -quality 100 had been tried, but to no avail.
Using ImageMagick, I think you want to output to PPM not PBM. Try
convert image.jpg image.ppm
or try the ascii version by using
convert image.jpg -compress none image.ppm
PBM is binary (black/white) and PGM is grayscale. If you want to keep color, then you need to use PPM.
Unfortunately, I believe that ImageMagick can only read DJVU format images. So you cannot write to it directly from ImageMagick.
I was able to convert my EXR image to a PNG using the techniques outlined in Image conversion from IFF and EXR formats to JPEG format .
convert 0007.exr /tmp/0007.png
Unfortunately the PNG looks quite dim.
What should I add to the imagemagick convert command line to increase the brightness?
Starting with this:
You could try -auto-gamma:
convert start.jpg -auto-gamma result.jpg
If the -auto-gamma overcooks the image for your liking, you could apply a percentage of it. So, here I clone the original image and apply auto-gamma to the clone but then only blend 80% back into the original because I feel auto-gamma overdoes it:
convert start.jpg \( +clone -auto-gamma \) \
-define compose:args=80 -compose blend -composite result.jpg
Or, another option, you could experiment with your particular images and maybe try using -modulate for the brightness, where 100% means "do nothing", so numbers over 100 increase the brightness:
convert start.jpg -define modulate:colorspace=LCHuv -modulate 160 result.jpg
You can try -auto-level, which will take the minimal value and the maximal value of your picture and then stretches the values to the full range of values:
convert input.exr -auto-level output.jpg
Note that if you picture was too bright and this does not help, then it might be that your image is stored with 32 Bit, while ImageMagick is working with 16 Bit and no HDRI support. 32 Bit input is supported if convert --version
either show Q32 as part of the version string or lists HDRI under features.
Depending on your operating system you might be able to install another variant of ImageMagick. For example, for Debian Buster we can use sudo apt list imagemagick* to see that the package imagemagick-6.q16hdri is available. Installing this package provides convert-im6.q16hdri, which allows reading 32 Bit EXR images.
EXR is in linear RGB colorspace. You want to convert it to non-linear sRGB colorspace in Imagemagick as:
Input:
convert image.exr -set colorspace RGB -colorspace sRGB output.png
I have 3 raw pictures in 16 bit depth. These pictures have all the same size and should represent a color channel each. So I want 1 raw to be red one raw to be blue and the last to be green and put them together into a tif.
If I "lose" the 16 bit depth and just get 8 bit depth for each color at this step its ok but not preferred. If there is another tool where this is possible with I'm open for it.
Kind of hard without the images, but something like this:
convert -depth 16 -size 800x600 gray:1.raw gray:3.raw gray:2.raw -combine -compress law image.tif
Specify the input files in the order R,G then B. I am assuming your red channel is in 1.raw, your green channel is in 3.raw and your blue channel is in 2.raw. Replace the filenames if not.
Set the size in the format widthxheight, and bit depth before reading.
Depending on the endianness of your data, you may need to put -endian msb or -endian lsb before you read in the files.
Specify -compress lzw to keep the output file small.
I created an 8-bit .tiff image ("test.tiff") containing a grid of 30 different color patches in the RGB color space using ImageMagick -convert.
When I convert this image into a jpeg (which is what I need) using:
convert -quality 100 -colorspace RGB -depth 8 test.tiff test.jpg
The identify -verbose command reveals that the resulting jpeg has several additional colors in the color table, each only taking up a few (1-4) pixels and residing very near the desired colors in RGB space. My assumption is that some kind of border bleeding is happening; maybe due to compression?
I don't understand why this border bleeding has occurred, especially given that it does not occur when I convert the tiff image to either a bmp or pcx image.
Thank you
By definition, JPEG is a lossy compression. The effects your experiencing are expected with the JPEG format. Setting the -quality of 100 will not have a 1-to-1 image result as tiff.
See additional answers:
Should I use JPG or TIFF for high-quality prints?
[...] because every time [JPEG] would save it it would generate some changes.
Is Jpeg lossless when quality is set to 100?
At [quality] 100, you just get the LEAST loss possible.
I don't know how you created your 30 colour swatch, or how your histogram looks, but you might try adding -dither None and -colors 30 options to your convert commands:
convert test.tiff -dither None -colors 30 ...
I am converting various PDFs uploaded by end users into images using following command
-density 140 -limit memory 64MB -limit map 128MB [pdffile] page.png
Here is the result. On the right we have original PDF and on the left output image. As you can see the colors are quite noticeably different.
What could be causing this and how fix it?
try following command:
-density 140 -limit memory 64MB -limit map 128MB -colorspace RGB [pdffile] page.png
Edit: I later discovered that ImageMagick can do it fine, I just needed to use -colorspace sRGB
My final command was:
convert -density 560 -limit memory 64MB -limit map 128MB \
-colorspace sRGB [pdffile] -scale 25% page.png
The oversampling and scaling down was to counter the poor anti-aliasing mentioned below.
Before I discovered that, here was my earlier solution...
In my case the colors produced by ImageMagick's convert were oversaturated, quite like those in the question. I was trying to convert this file using IM 6.7.7.10-6ubuntu3.
-resample 100 made no difference.
-colorspace RGB seemed to produce more accurate saturations, but the entire image was darker than it should have been.
Curiously, this suggestion to use GhostScript instead of ImageMagick for the conversion, produced very close to the correct colors:
gs -q -sDEVICE=png16m -dSubsetFonts=true -dEmbedAllFonts=true \
-sOutputFile=page.png -r200 -dBATCH -dNOPAUSE [pdffile]
(The original suggestion passed the -dUseCIEColor option, but in my case this appeared to reduce the gamma: light pixels were fine, but the dark pixels were too dark, so I removed it.)
After that, the only thing that bothered me was that the anti-aliasing/edges were a little off in places (especially visible on curves passing 45 degrees). To improve that, I created the output at four times the required resolution, and then scaled down afterwards, rendering those errors almost imperceptible. Note that I had to use ImageMagick's -scale for this, and not -geometry or -resize, in order to avoid bicubic ringing effects.
Use the -resample option:
-density 140 -resample 100 -limit memory 64MB -limit map 128MB [pdffile] page.png
Open Source MuPDF util mutool retains color and size using default parameters below
you need though to list the pages separated by a comma at the end of the command.
mutool draw -o draw%d.png abook.pdf 1,2
Otherwise if using Linux try Windows for better colorspace RGB interpretation when using imagemagick's convert.
The following images show how anti-aliasing improves if you sample at a higher resolution and then scale down.
Although 1120 was slightly better quality than 560, it took a long time to convert, so I would probably choose 560 for a good time:quality trade-off.
-colorspace sRGB -density 140
-colorspace sRGB -density 280 -scale 50%
-colorspace sRGB -density 420 -scale 33.3333%
-colorspace sRGB -density 560 -scale 25%
-colorspace sRGB -density 1120 -scale 12.5%
(It is easier to see the difference if you download the last two images and flip between them in your favourite image viewer. Or scroll up this list of images, instead of down. You should seem them becoming progressively uglier.)