Yes, I think so...LINE is the number of consecutive black pixels.
$ (1,3)$1
1 3
I need to have it match the rank of xb to do the matching in E. (as far as
I know)
$ xb
58 157
On Wed, Feb 19, 2014 at 1:26 PM, Raul Miller wrote:
>lineStarts=:((1, LINE) $ 1) E. y
>lineEnds=: |."1
lineStarts=:((1, LINE) $ 1) E. y
lineEnds=: |."1 ((1, LINE) $ 1) E. |."1 y
(1,3)$1
1 1 1
This matches your intent? (I am not objecting, just making sure I
understand.)
Thanks,
--
Raul
On Wed, Feb 19, 2014 at 1:00 PM, Joe Bogner wrote:
> I came up with a slightly different approac
I came up with a slightly different approach that seems to work well on my
test cases so far:
http://drp.io/jsnW
xb =: 600 >: x2 NB. make 1 if less than 600 combined RGB
lineDetect=: 4 : 0
LINE=:x
lineStarts=:((1, LINE) $ 1) E. y
lineEnds=: |."1 ((1, LINE) $ 1) E. |."1 y
lD=:lineStarts+.lineEnds
On Wed, Feb 19, 2014 at 11:06 AM, Joe Bogner wrote:
> Input: http://drp.io/files/5304d74f7ba1d.jpg
> Output: http://drp.io/files/5304d7049f938.jpg
Pretty!
(Or am I just showing how warped my tastes are?)
Thanks,
--
Raul
--
Don, Jan-Pieter - Thanks for the other ideas
Raul, I will give that a shot. It looks like a much cleaner approach. Just
to prove it to myself that something was possible, I hacked together this
awful version. It works reasonably well though. Here's a version on the IRS
tax table just for fun.
Inp
I'd like to introduce you to ~:/\
~:/\ is an illustration of one of the things I really like about J. It is
equivalent to 2 | +/\ ] but without the possibility of overflow. And it
turns out to be really handy when reasoning about bit operations.
One way of describing it is as a slightly flawed se
Funny enough I was talking with a colleague about this a few days ago. We
came up with these links:
http://stackoverflow.com/questions/2596722/is-there-any-super-fast-algorithm-for-finding-lines-on-picture
or this one
http://en.wikipedia.org/wiki/Hough_transform
These tackle the more general pr
You may not be interested in a little reading on seismic convolution. This
is a process to recognize lines (horizons, changes in the propagation of
sound waves causing a reflection) in seismic data. Seismic recordings of
reflections (echoes) from a source (sound generator) to geophones (to
record t
On Wed, Feb 19, 2014 at 7:25 AM, Henry Rich wrote:
> Look at
>
> (1 10$0) E. image
>
> or
>
> (10 $ 0) E. line
>
>
Thanks Henry, that worked well. I have a version that seems to work now
(albeit clunky)
]lines=: 4 10 $ (0 0), (5 $ 1), (3 $ 0),(5 $ 1), (0 0 0), (1 1), (10 $ 1)
lineStarts=:(1 5$1)
Look at
(1 10$0) E. image
or
(10 $ 0) E. line
Beware of a previously-reported bug in non-literal E.
Henry Rich
On 2/19/2014 7:04 AM, Joe Bogner wrote:
I can get it aligned, but I'd like to flag the start of the line and not
just when I first detect a line.
For example, I'm saying a line is
I can get it aligned, but I'd like to flag the start of the line and not
just when I first detect a line.
For example, I'm saying a line is when 10 consecutive pixels are 0. This
flags the 10th pixel. When I reshape and align, I'm losing the line starts.
I apologize for the poor wording of this. P
Raul, thanks! Yes, that solved the mismatched shape problem. Now I just
need to tinker with getting it aligned.
On Tue, Feb 18, 2014 at 9:20 PM, Raul Miller wrote:
> It looks like you are losing 9 pixels from each array.
>
> The easy answer would be to put them back. Ideally, you would try to pu
It looks like you are losing 9 pixels from each array.
The easy answer would be to put them back. Ideally, you would try to put
some back on each side so that the result is not too far off center.
Thus:
hlines2=: 58 157 {. 58 _152 {. hlines
vlines2=: 58 157 {. _43 157 {. vlines
Note that
I'm testing out OCRing PDF tables using Tesseract OCR. I'm borrowing the
concept from here:
http://craiget.com/extracting-table-data-from-pdfs-with-ocr/
I've made good progress using the PPM examples on rosetta code and am
having fun with it. (NOTE: I am starting off with an image resized down to
14 matches
Mail list logo
