Legacy ImageMagick Discussions Archive

Just FYI: Tesseract recognizes all lines in your sample correctly.

Cinemaslides (I'm the author) is a tool to create Digital Cinema Packages (DCPs) from all kinds of images -- slideshows really, including movies (rapid slideshows). ImageMagick is the central tool in there for conforms, resizes, color transforms etc. No way to do it that simple without IM.

jp2:rate is probably too low.

Yes, it's an attractively hard problem for any kind of non-OCR approach. From an OCR-centric point-of-view, though, it might be close to trivial, shape recognition and some intelligence towards the concept of outlines.

Ok, there's one way to do it -- if somewhat cumbersome and, indeed, horrifyingly slow :) Thanks for the effort, snibgo! The problem, I think, with this approach is that it deals with the artefacts of an initial operation (background floodfill with outline color) which is not suitable in the first ...

Right, but the kernels are fixed-size. Thus whatever it will match is fixed-size, from what I understand?

I found a related topic (area opening and closing): Morphology, area open and close . This is about selecting contiguous areas bigger (or smaller) than a specific amount of pixels. In ...

snibgo, very interesting idea indeed. Thanks for the suggestion. Going to experiment with it tomorrow. Hardcoded pixel matches though, yes? That's probably going to be a problem for variable-sized input.

I'm trying to improve OCR/tesseract legibility of text rendered in an outline font. Text spacing is dense enough that a bunch of letter pairs will touch: http://minus.com/lyPtV8gTWD0SP . Feeding this original through tesseract will not output anything useful (completely garbled).

My best shot at it ...

Anthony, in some use cases having a image-data-only hash is extremely useful. Now if the hash algorithm used was configurable ...

magick wrote:It looks like the docs are wrong (we'll correct that). The source code uses 0.04045 for K0.

Ugh, I was grepping an ancient version. Apparently 6.6.3-10 was the last one that used 0.03928f. Sorry for the noise.

magick, I see that magick/colorspace.c is using 0.03928f for K0 (just like the docs at http://www.imagemagick.org/script/command-line-options.php#colorspace section sRGB say.) I'm kind of staring at http://en.wikipedia.org/wiki/SRGB#Theory_of_the_transformation which discusses K0 as 0.04045 in order ...

3. Get the coordinates from the filename ... It's step 3 that I have a problem with. There just doesn't seem to be a way to extract the coordinates from the filename.
With ruby this is one way to do that:
x,y = 'tile_3_-21.png'.match( /(-?\d+)_(-?\d+)/ )[ 1 .. -1 ].collect { |n| n.to_i }
which ...

Moving the center of a sigmoid function (also known as "s-curves") changes rates of both ends. Looking at an "S" makes "shoulder" and "toe" quite obvious.

For an alternative (to Fred's awesome suggestions) look at http://unpaper.berlios.de/

Well, see http://www.digitalpreservation.gov/formats/content/tiff_tags.shtml and http://www.awaresystems.be/imaging/tiff/tifftags/compression.html which says (bottom of the page):
LibTiff adds support for some compression schemes that are not part of the specification and are somewhat less common ...