Installed ImageMagick-7.0.4-7-Q16-x64-dll.exe for resolving the issue of Tesseract facing problems with smaller font explained in this Stackoverflow question Is there any way to improve tesseract OCR with small fonts?
I ran the following convert command. But it still says invalid parameter.
C:\Users\rt\Desktop\Sample_Files>convert -resize 400% image5.jpg image5out.jpg
Invalid Parameter - 400%
and when I ran this
C:\Users\rt\Desktop\Sample_Files>where convert.exe
C:\Windows\System32\convert.exe
so just one convert.exe, I guess which belongs to windows convert.
I am missing something or something wrong with Tesseract or ImageMagick? can anyone help ?
convert is now replaced by magick to avoid clashing with Windows CONVERT.EXE.
identify becomes magick identify.
mogrify becomes magick mogrify. Likewise, animate, compare, compose and stream.
Or alternatively, to keep using the old command names, you must tick the Legacy box when installing ImageMagick.
Related
Edit July 7, 2017: Downgrading to ImageMagick 6.9.5 solved this problem, which may be Cygwin-specific. I still don't know the underlying cause.
I need to extract data via OCR from images in PDF reports published by Chicago Public Schools. An example PDF is here (NB: this link downloads the file automatically rather than opening it in the browser). Here's a sample image (from PDF page 11, print page 8), extracted with pdfimages -png version 0.52.0 on Cygwin:
I'd like to crop each bar into its own file and extract the text with OCR. But when I try this with ImageMagick (version 7.0.4-5 Q16 x86_64 2017-01-25 according to convert -version), using the command convert chart.png -crop 320x600+0+0 bar.png, I get this image, with horizontal lines that interfere with OCR:
Running pdfimages to extract to PPM format first and then converting to PNG while cropping gives the same result, as does round-trip converting the extracted images to SVG format with ImageMagick's rsvg delegate, and fiddling with the PNG alpha channel changes the line's colors from gray to white or black but doesn't eliminate them. I've found a workaround of round-trip converting extracted images through JPG (introducing ringing artifacts, which I hope are irrelevant). But I don't see why I should have to do this. Incidentally, ImageMagick introduces the lines to PNGs even if I run a null conversion convert chart.png chart.png, which ought to leave the image unchanged:
I have found other complaints that PDF software adds horizontal lines to images, but none of them exactly matches this problem. A discussion thread mentions that versions of the PDF standard somehow differ in their treatment of alpha channels, but my knowledge of graphics is too poor understand the discussion fully; besides, my images get horizontal lines added after they're extracted from the PDF, because of something internal to ImageMagick. Can anyone shed some light on the causes of the grey lines?
Using the latest ImageMagick 7.0.6.0 Q16 Mac OS X, I get a good result. As mentioned above by Bonzo, the correct syntax for IM 7 is magick rather than convert. The use of convert reverts to IM 6. Also do not use magick convert either.
magick chart.png -crop 320x600+0+0 +repage bar.png
If this does not work for you, then there must have been a bug in your older version of IM 7. So you should then upgrade.
Note also the +repage is needed to remove the virtual canvas
I have a problem using the tool convert (imagemagick) to remove metainformation of pictures to make them smaller for faster delivery in websites.
When I use the convert command with following parameters:
convert -format png -strip pic1.png pic2.png
then the converted picture is much more darker than the original one.
I also tried to require the colorspace of the original picture with:
convert -format png -colorspace sRGB -strip pic1.png pic2.png
but it's the same problem.
Has anyone an idea how to solve it?
These are the example pictures:
(Original) Pic1:
(Converted) Pic 2:
The problem is the installed version 6.7.7 of ImageMagick (Standard-Version of Linux Mint 17)
In version 6.4 and (said in comment) in version 6.9 it works.
So the 6.7.7 version is buggy in that case.
I need to resize a lot of jpeg images from the original to 220x160 for a website.
I'm currently just opening in paint and resizing them manually, then adding -w to the end of the filename.
Note that we are not resizing them using html on the website itself because it's slowing down the website.
Is there a way to resize e.g. 10+ images to 220x160 and append -w to all the filenames without doing it manually, and without using software that I must buy?
Thanks
You can do that with ImageMagick which is free and available for Windows and Linux and OSX here.
To do a single image, you would type the following into the Command Prompt in Windows:
convert input.jpg -resize 220x160! input_w.jpg
I can probably work out how to do it in a loop, if you wait a while, or someone else may tell me the FOR syntax for Windows...
Ok, Windows isn't my thing, but something like this to make all the smaller images and save them into a subdirectory called SMALL
MKDIR SMALL
FOR %x in (*.jpg) DO convert %x -resize 220x160! SMALL\%~nx_w.jpg
Irfanview is free and has command line processing which you can use in a batch file.
I'm using a nice enough cms (locomotive(github)) to allow some non-tech savy users to upload pictures to the system. The program is able to resize and crop pictures to any given size.
Trouble is, Internet explorer doesn't know how to deal with CMYK-encoded images. The users of this app are not exactly tech-savy; asking them to transform their images from CMYK to RGB is not an option. I'd like to modify locomotive so that it does the change automatically. I've been trying this for some hours but had no luck so far.
This is what I have found:
Locomotive uses dragonfly to perform the resizing.
Concretely, it uses dragonfly's imagemagick module.
The file that defines how Dragonfly is used in locomotive can be found here.
There is also a dragonfly initializer file.
I have also found that what (think) I need is adding a -colorspace RGB option to the parameter sent to Imagemagick by Dragonfly. It doesn't look like Dragonfly provides an easy option to do that.
I've tried several things, the last one consisting on monkeypatching Dragonfly's Imagemagick Processor so that the -colorspace RGB option is always used. I've added this in locomotive's config/initializers/dragonfly.rb:
# locomotive's config/initializers/dragonfly.rb
# ... Locomotive's default initialization
module Dragonfly
module ImageMagick
class Processor
alias :old_convert :convert
def convert(temp_object, args='', format=nil)
args += ' -colorspace RGB' # force RGB in all thumbnails
old_convert(temp_object, args, format)
end
end
end
end
I was pretty sure that this should work, but unfortunately it doesn't. And I have run out of ideas. Can anyone help?
On the commandline, I sometimes need to add -type truecolor to make colorspace conversions work reliably:
convert cmyk.jpeg -colorspace rgb -type truecolor rgb.jpeg
Maybe you try to add it in your code as well?
From the related list to the right, might this SO answer help?
Properly converting a CMYK image to RGB with RMagick
Unfortunately there doesn't seem to be a straightforward way to do this with Dragonfly. I've given up.
What command or series of commands could I execute from the CLI to recursively traverse a directory tree and reduce the bit-depth of all PNG files within that tree from 24bpp to 16bpp? Commands should preserve the alpha layer and should not increase the file size of the PNGs - in fact a decrease would be preferable.
I have an OSX based system at my disposal and am familiar with the find command so am really more keen to to locate a suitable PNG utility command.
Install fink
Say "fink install imagemagick" (might be "ImageMagick")
"convert -depth 16 old/foo.png new/foo.png"
If that did what you want, wrap it in a find call and be happy. If not, say "convert -help" and RTF-ImageMagick-M. :)
Optional: "fink install pngcrush" and run that as a second pass after the convert pass.
AFAIK the only PNG format that supports the alpha layer is PNG-24; Reducing the PNG to another format may require specifying a transparent color in a CLUT, which will not give you the output you want.
From the feature list on PNG's website:
8- and 16-bit-per-sample (that is, 24- and 48-bit) truecolor support
full alpha transparency in 8- and 16-bit modes, not just simple on-off transparency like GIF
... which I read to mean that anything other than PNG-24 or PNG-48 does not support full alpha transparency.