Re: Drawing in images?

Re: Drawing in images?

[MON KEY]

> a) use clever already existing way, unknown to me, or

Could parts of ../lisp/textmodes/artist.el be used?

The rectangling feature is usable for setting reasonable rhombus'
At the very least the heuristics of its rubber-banding are already available.

BTW: This would be a _killer-feature_  if the bounding box could be rotated.
Moreso, with key commands e.g. rotate-box-left/right..  :=]

Few image editors do this well if at all (including imagemagick).

elisp certainly has fast enough routines available with `asin' `atan' et al.
If you should happen to find a way to make the box happen please
consider leaving room for rotations - design constraints permitting of
course.

FWIW the ability to rotate/skew boxes in OCR apps is one of the
aspects of that task that is lacking in nearly all commercial products
(the free counterparts all seem to be based on the same legacy HP code
as the commercial derivatives) and it seriously hinders the viability
of the output.

If a bounding box could be implemented as a working part of Emacs
there are some really amazing applications for applying
annotations/text-properties/alist lookups on 'regions' of processed
text/images...

s_P

Re: Drawing in images?

[joakim]

MON KEY <monkey@sandpframing.com> writes:

>> a) use clever already existing way, unknown to me, or
>
> Could parts of ../lisp/textmodes/artist.el be used?
>
> The rectangling feature is usable for setting reasonable rhombus'
> At the very least the heuristics of its rubber-banding are already available.
>
> BTW: This would be a _killer-feature_  if the bounding box could be rotated.
> Moreso, with key commands e.g. rotate-box-left/right..  :=]
>
> Few image editors do this well if at all (including imagemagick).
>
> elisp certainly has fast enough routines available with `asin' `atan' et al.
> If you should happen to find a way to make the box happen please
> consider leaving room for rotations - design constraints permitting of
> course.
>
> FWIW the ability to rotate/skew boxes in OCR apps is one of the
> aspects of that task that is lacking in nearly all commercial products
> (the free counterparts all seem to be based on the same legacy HP code
> as the commercial derivatives) and it seriously hinders the viability
> of the output.
>
> If a bounding box could be implemented as a working part of Emacs
> there are some really amazing applications for applying
> annotations/text-properties/alist lookups on 'regions' of processed
> text/images...


This should be possible by drawing a SVG image on top of another
image. The SVG image is XML which can be generated in a buffer within
Emacs. 

One difficulty with this aproach is that there isnt really much support for
alpha channels in Emacs. Also latency in interactive use might not be
spectacular. 

I havent used commercial OCR much at all, so its interesting to hear
your view.

>
> s_P
-- 
Joakim Verona

Re: Drawing in images?

[MON KEY]

On Thu, Aug 27, 2009 at 2:31 AM, <joakim@verona.se> wrote:
> MON KEY <monkey@sandpframing.com> writes:
>> there are some really amazing applications for applying
>> annotations/text-properties/alist lookups on 'regions' of processed
>> text/images...
>
> This should be possible by drawing a SVG image on top of another
> image. The SVG image is XML which can be generated in a buffer within
> Emacs.
>
> One difficulty with this aproach is that there isnt really much support for
> alpha channels in Emacs. Also latency in interactive use might not be
> spectacular.
>
> One difficulty with this aproach is that there isnt really much support for
> alpha channels in Emacs.

Why worry about layering with alpha channels at all then? Obv. SVG is
lighter (from a data size perspective) than a .bmp or .jpg but its
still considerably heavier than an Emacs text/string.

Isn't it possible to use an image as an Emacs window's background (if
not can't GTK be leveraged towards that end)?

Why not just use a smallish glyph e.g. `.' (or something smaller
dedicated to the purpose) and the text based facilites from artist.el
(or bespoke equivalent).
AIUI the position of the glyphs isn't necessarily the same as the
_size_ of the glyph as rendered.

Would a layered placement of an SVG provide/allow more user accuracy
than an equivalently positioned glyph. If so, how much more? Does the
gain warrant a departure from a text oriented approach? Why reinvent
Emacs as an image editor? It seems more reasonable to reorient the
task to an arena where Emacs is best acclimated - as a _text_ editor
:)

> Also latency in interactive use might not be spectacular.

If a window could have the image as a background over which text could
be displayed then interactive latency needn't necessarily be an issue.
Scaling/rescaling the box could be made by 'setting' a new rectangle
(or other shape)... e.g. artist-select-op-rectangle.

This approach might allow for interesting `annotation' applications as
well e.g. `artist-select-op-text-see-thru'
`artist-select-op-text-overwrite'. The use of text-properties here
could be are a very valuable feature; they are native to emacs, ought
to be able to carry much of the same information as an svg->xml
string, and can already interact with other native elisp facilities
and data structures without the need for additional XML
parsing/serializing routines.

> Joakim Verona

s_P

Re: Drawing in images?

[joakim]

MON KEY <monkey@sandpframing.com> writes:

> On Thu, Aug 27, 2009 at 2:31 AM, <joakim@verona.se> wrote:
>> MON KEY <monkey@sandpframing.com> writes:
>>> there are some really amazing applications for applying
>>> annotations/text-properties/alist lookups on 'regions' of processed
>>> text/images...
>>
>> This should be possible by drawing a SVG image on top of another
>> image. The SVG image is XML which can be generated in a buffer within
>> Emacs.
>>
>> One difficulty with this aproach is that there isnt really much support for
>> alpha channels in Emacs. Also latency in interactive use might not be
>> spectacular.
>>
>> One difficulty with this aproach is that there isnt really much support for
>> alpha channels in Emacs.
>
> Why worry about layering with alpha channels at all then? Obv. SVG is
> lighter (from a data size perspective) than a .bmp or .jpg but its
> still considerably heavier than an Emacs text/string.

True.

> Isn't it possible to use an image as an Emacs window's background (if
> not can't GTK be leveraged towards that end)?

I its not currently possible, but Miles Bader has a image background
patch I think.

> Why not just use a smallish glyph e.g. `.' (or something smaller
> dedicated to the purpose) and the text based facilites from artist.el
> (or bespoke equivalent).
> AIUI the position of the glyphs isn't necessarily the same as the
> _size_ of the glyph as rendered.

Maybe so, but how does one place Emacs glyphs on pixel coordinates then?

> Would a layered placement of an SVG provide/allow more user accuracy
> than an equivalently positioned glyph. If so, how much more? Does the
> gain warrant a departure from a text oriented approach? Why reinvent
> Emacs as an image editor? It seems more reasonable to reorient the
> task to an arena where Emacs is best acclimated - as a _text_ editor
> :)

True. However, another thing I'm working on is embedding other
applications inside Emacs windows with Xembed, a facility I named
Xwidgets. I aim to patch Inkscape so it supports xembed, so it can be
embedded inside Emacs. Then one could conveniently edit the SVG as xml
in emacs, and graphically inside an embedded Inkscape, that could
furthermore be controlled with Emacs-lisp. (Daniel Hackney is working on
something similar using the Uzbl webkit browser and the xwidget patch)

One aproach doesnt exclude the other however.

>> Also latency in interactive use might not be spectacular.
>
> If a window could have the image as a background over which text could
> be displayed then interactive latency needn't necessarily be an issue.
> Scaling/rescaling the box could be made by 'setting' a new rectangle
> (or other shape)... e.g. artist-select-op-rectangle.
>
> This approach might allow for interesting `annotation' applications as
> well e.g. `artist-select-op-text-see-thru'
> `artist-select-op-text-overwrite'. The use of text-properties here
> could be are a very valuable feature; they are native to emacs, ought
> to be able to carry much of the same information as an svg->xml
> string, and can already interact with other native elisp facilities
> and data structures without the need for additional XML
> parsing/serializing routines.

For my current use-case, interactively defining areas in an image, using
text would be fine, even though I'm having trouble seeing how one would
achieve pixel precision that way.

>> Joakim Verona
>
> s_P
>
-- 
Joakim Verona

Re: Drawing in images?

[MON KEY]

Joakim,

On Thu, Aug 27, 2009 at 3:05 PM, <joakim@verona.se> wrote:
>
> Maybe so, but how does one place Emacs glyphs on pixel coordinates then?
>

Presumably the same way one places an SVG.

>
> One aproach doesnt exclude the other however.
>
Which mutual exclusion are you dereferencing?
UZBL /<-> Xxidgets
or
SVG /<-> text-glyph-based

>
> For my current use-case, interactively defining areas in an image, using
> text would be fine, even though I'm having trouble seeing how one would
> achieve pixel precision that way.
>

Most likely one can't it would have to be ``good enough''.

That said, I'm having trouble understanding how one can achieve
reasonable pixel prec. when placing an SVG non-interactively. I don't
see where this will be better than ``good-enough''.

If the precision of the SVG is to rely on the use of mouse-events in
Emacs to record Emacs posn(s) x,y and subsequent mapping of these
posn(s) to corresponding pixel positions in the source image and SVG
`overlay' there _will_ be multiple user overshoots and mis-placements.
It is difficult enough to set a dynamically scalable box with a GUI
let alone reliably setting posn(s) without the aid of an interactively
scalable box.

This is exactly the issue with setting a slice in docview (see
Stefan's comments above). In the absence of visual feedback from Emacs
it is _very_ difficult to be sure which box is getting set and by the
time you find out if you did it correctly Emacs is already well into
the process of regenerating the image cache.

What I am suggesting is that barring an entirely embedded external GUI
within an Emacs window (which is your use case) non-interactive SVG
layering will in many instances none the less remain less precise than
an inexact but interactive placement of a text base rectangle. Where
this is the case, and where an artist.el style text based rectangle
would otherwise suffice it seems more in keeping with Emacs WODT to
use a text based approach of an existing package and would allow
easier integration with emacs procedures which are not as-yet
Xembed/UZBL aware.

> Joakim Verona

s_P

Re: Drawing in images?

[Chong Yidong]

joakim@verona.se writes:

> This should be possible by drawing a SVG image on top of another
> image. The SVG image is XML which can be generated in a buffer within
> Emacs.

If I understand you, you're suggesting to generate an SVG image that
contains a bitmap (the underlying image), plus a rectangle (or whatever
else), correct?  This approach has the great advantage that it can be
implemented entirely in Lisp.  Anyone want to give it a shot?

Re: Drawing in images?

[joakim]

Chong Yidong <cyd@stupidchicken.com> writes:

> joakim@verona.se writes:
>
>> This should be possible by drawing a SVG image on top of another
>> image. The SVG image is XML which can be generated in a buffer within
>> Emacs.
>
> If I understand you, you're suggesting to generate an SVG image that
> contains a bitmap (the underlying image), plus a rectangle (or whatever
> else), correct?  This approach has the great advantage that it can be
> implemented entirely in Lisp.  Anyone want to give it a shot?

I might :)

Another idea:
Provide a new image spec :map-draw, which tells Emacs to draw the
graphic commands in the :map property.


-- 
Joakim Verona

Re: Drawing in images?

[joakim]

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

Chong Yidong <cyd@stupidchicken.com> writes:

> joakim@verona.se writes:
>
>> This should be possible by drawing a SVG image on top of another
>> image. The SVG image is XML which can be generated in a buffer within
>> Emacs.
>
> If I understand you, you're suggesting to generate an SVG image that
> contains a bitmap (the underlying image), plus a rectangle (or whatever
> else), correct?  This approach has the great advantage that it can be
> implemented entirely in Lisp.  Anyone want to give it a shot?

Here's an attempt. Its hardly industrial strength, but seems to work.
Test with m-x  dragbox-start, enter an image file name compatible with
svg, I tried png. Then set the corner coords for the box with LMB and RMB.




[-- Attachment #2: dragbox-test.el --]
[-- Type: text/plain, Size: 3164 bytes --]



(setq dragbox-image-url "")
(setq dragbox-image-width 744)
(setq dragbox-image-height 1052)

(setq dragbox-x1y1 '(0 . 0))
(setq dragbox-x2y2 '(100 . 100))

(defun dragbox-start (image-file)
  "start here"
  (interactive "fimage file:")
  (get-buffer-create "*dragbox*")
  (switch-to-buffer  "*dragbox*")
  (setq dragbox-image-url (concat "file://" (expand-file-name image-file)))
  (dragbox-update-box-from-state))


(defun dragbox-make-svg-data (x y width height image-url)
  `((svg
         ((xmlns:dc . "http://purl.org/dc/elements/1.1/")
          (xmlns:cc . "http://creativecommons.org/ns#")
          (xmlns:rdf . "http://www.w3.org/1999/02/22-rdf-syntax-ns#")
          (xmlns:svg . "http://www.w3.org/2000/svg")
          (xmlns:xlink . "http://www.w3.org/1999/xlink")
          (xmlns . "http://www.w3.org/2000/svg")
          (width . ,(number-to-string dragbox-image-width))
          (height . ,(number-to-string dragbox-image-height))
          (id . "svg2"))
         (g
          ((id . "layer1"))
          (rect
           ((style . "fill:#cfcfcf;fill-opacity:1")
            (width . ,(number-to-string dragbox-image-width))
            (height . ,(number-to-string dragbox-image-height))
            (x . "0")
            (y . "0")))
          (image ((y . "0")
                  (x . "0")
                  (width . ,(number-to-string dragbox-image-width))
                  (height . ,(number-to-string dragbox-image-height))
                  (xlink:href . ,image-url)
                 ))
          (rect
           ((style . "color:#000000;fill:#000000;fill-opacity:0.5;fill-rule:nonzero;stroke:#000000;stroke-width:1;marker:none;visibility:visible;display:inline;overflow:visible;enable-background:accumulate;stroke-opacity:0.5")
            (id . "dragbox")
            (width . , (number-to-string width) )
            (height . ,(number-to-string height))
            (x . ,(number-to-string x))
            (y . ,(number-to-string y))))

                 
          ))))

(defun dragbox-lmb-click-handler ()
            (interactive)
            (setq dragbox-x1y1 (dragbox-extract-event-coords last-input-event))
            (dragbox-update-box-from-state)
            )

(defun dragbox-rmb-click-handler ()
            (interactive)
            (setq dragbox-x2y2 (dragbox-extract-event-coords last-input-event))
            (dragbox-update-box-from-state)
            )

(defun dragbox-extract-event-coords (event)
   (caddr(cadr last-input-event))
  )


(define-key image-mode-map [down-mouse-1] 'dragbox-lmb-click-handler)
(define-key image-mode-map [down-mouse-2] 'dragbox-rmb-click-handler)

(defun dragbox-update-box (x y width height)
  (fundamental-mode)

  (erase-buffer)
  (xml-print (dragbox-make-svg-data x y width height dragbox-image-url))
  (image-mode)
    )

(defun dragbox-update-box-from-state ()
  (let*
      ((x1 (car dragbox-x1y1))
       (y1 (cdr dragbox-x1y1))
       (x2 (car dragbox-x2y2))
       (y2 (cdr dragbox-x2y2))
       (w (- x2 x1))
       (h (- y2 y1)))
    (message "(%d %d) (%d %d) w:%d h:%d" x1 y1 x2 y2 w h)
    (dragbox-update-box
     x1
     y1
     w
     h)))

                      


[-- Attachment #3: Type: text/plain, Size: 20 bytes --]



-- 
Joakim Verona

Re: Drawing in images?

[MON KEY]

On Wed, Sep 16, 2009 at 3:04 PM,  <joakim@verona.se> wrote:
>
> Here's an attempt. Its hardly industrial strength, but seems to work.
> Test with m-x  dragbox-start, enter an image file name compatible with
> svg, I tried png. Then set the corner coords for the box with LMB and RMB.
>

Joakim thanks for taking a shot at this.  This is very exciting.
Unfortunately I can't evaluate. After invoking the `dragbox-start'
comman with both .png and .jpg image-file types the  *dragbox* buffer
returns some svg data and a message:

=> "Invalid image type `svg'"

Not sure if the local w32 builds are compiled with libsvg support out
of the box.
I've not been able to get svg functionality to evaluate on the
following w32 systems.

- 23.1.50.1 (i386-mingw-nt5.1.2600) of 2009-06-30 on LENNART-69DE564 (patched);
- 23.0.91.1 (i386-mingw-nt5.1.2600) of 2009-02-26 on SOFT-MJASON;
- 23.1.1 (i386-mingw-nt5.1.2600) of 2009-07-30 on SOFT-MJASON;

Can these functions be evaluated successfully on a non CVS emacs?
Likewise, if so, can these functions be evaluated on a non CVS emacs on w32?

Also, as a side note in lieu of a future dragbox package; in a fresh
environment when evaluating these functions on the two 23.*
SOFT-MJASON  builds referd above the key bindings on
image-mode-mode-map of `dragbox-lmb-click-handler' and
`dragbox-rmb-click-handler' didn't take until after a (require
'image-mode). Additionally, I needed a (require 'xml) to get the
invocation of `xml-print' in `dragbox-update-box' to evaluate.

Just to make sure I also tried evaluating CYD's svg example here:
(URL `http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg01166.html')
I know this works on a GNU box but on the w32 systems get:
=> "Invalid image type `svg'"

Any advice as to what needs to be done to get supprot for `svg' on w32?

I look forward to testing the dragbox functions on a GNU box later this evening.

s_P

Re: Drawing in images?

[Lennart Borgman]

On Thu, Sep 17, 2009 at 9:13 PM, MON KEY <monkey@sandpframing.com> wrote:
>
> Joakim thanks for taking a shot at this.  This is very exciting.
> Unfortunately I can't evaluate. After invoking the `dragbox-start'
> comman with both .png and .jpg image-file types the  *dragbox* buffer
> returns some svg data and a message:
>
> => "Invalid image type `svg'"
>
> Not sure if the local w32 builds are compiled with libsvg support out
> of the box.
> I've not been able to get svg functionality to evaluate on the
> following w32 systems.
>
> - 23.1.50.1 (i386-mingw-nt5.1.2600) of 2009-06-30 on LENNART-69DE564 (patched);
> - 23.0.91.1 (i386-mingw-nt5.1.2600) of 2009-02-26 on SOFT-MJASON;
> - 23.1.1 (i386-mingw-nt5.1.2600) of 2009-07-30 on SOFT-MJASON;
>
> Can these functions be evaluated successfully on a non CVS emacs?
> Likewise, if so, can these functions be evaluated on a non CVS emacs on w32?

I ship some image libraries with Emacs+EmacsW32, but I do not know
what to ship for svg. The news file says

  *** Emacs now supports the SVG image format through librsvg2.

I do not know where to get this for w32. Can anyone tell me?

Re: Drawing in images?

[Lennart Borgman]

On Thu, Sep 17, 2009 at 11:04 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
>
> I ship some image libraries with Emacs+EmacsW32, but I do not know
> what to ship for svg. The news file says
>
>  *** Emacs now supports the SVG image format through librsvg2.
>
> I do not know where to get this for w32. Can anyone tell me?

Eh, sorry for the noise. I have found it and will add it. It is here:

  http://ftp.gnome.org/pub/GNOME/binaries/win32/librsvg/2.26/

Re: Drawing in images?

[Jason Rumney]

Lennart Borgman wrote:

> I ship some image libraries with Emacs+EmacsW32, but I do not know
> what to ship for svg. The news file says
>
>   *** Emacs now supports the SVG image format through librsvg2.
>
> I do not know where to get this for w32. Can anyone tell me?
>   

See nt/INSTALL. There are at least a dozen libraries needed in addition 
to librsvg, and some of them are unstable on Windows.

Re: Drawing in images?

[Lennart Borgman]

On Fri, Sep 18, 2009 at 1:00 AM, Jason Rumney <jasonr@gnu.org> wrote:
> Lennart Borgman wrote:
>
>> I ship some image libraries with Emacs+EmacsW32, but I do not know
>> what to ship for svg. The news file says
>>
>>  *** Emacs now supports the SVG image format through librsvg2.
>>
>> I do not know where to get this for w32. Can anyone tell me?
>>
>
> See nt/INSTALL. There are at least a dozen libraries needed in addition to
> librsvg, and some of them are unstable on Windows.


Thanks. It looks, eh, totally unusable for those that does not build
Emacs themselves then.

From nt/INSTALL it looks like librsvg could have a lot of dependencies
and that these are dependent on the options used to build the dll.
Until there are some binaries available that are easy to install is it
really worth the effort trying to use this in Emacs?

Re: Drawing in images?

[joakim]

[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]

MON KEY <monkey@sandpframing.com> writes:

> On Wed, Sep 16, 2009 at 3:04 PM,  <joakim@verona.se> wrote:
>>
>> Here's an attempt. Its hardly industrial strength, but seems to work.
>> Test with m-x  dragbox-start, enter an image file name compatible with
>> svg, I tried png. Then set the corner coords for the box with LMB and RMB.
>>
>
> Joakim thanks for taking a shot at this.  This is very exciting.
> Unfortunately I can't evaluate. After invoking the `dragbox-start'
> comman with both .png and .jpg image-file types the  *dragbox* buffer
> returns some svg data and a message:

Thanks for testing. I added the requires you mention, and cleaned up the
code a little bit for readability. Still not industrial strength, but
works here(but I only tested it on a single png file). Looking forward
to your further comments.

> => "Invalid image type `svg'"
>
> Not sure if the local w32 builds are compiled with libsvg support out
> of the box.
> I've not been able to get svg functionality to evaluate on the
> following w32 systems.
>
> - 23.1.50.1 (i386-mingw-nt5.1.2600) of 2009-06-30 on LENNART-69DE564 (patched);
> - 23.0.91.1 (i386-mingw-nt5.1.2600) of 2009-02-26 on SOFT-MJASON;
> - 23.1.1 (i386-mingw-nt5.1.2600) of 2009-07-30 on SOFT-MJASON;
>
> Can these functions be evaluated successfully on a non CVS emacs?
> Likewise, if so, can these functions be evaluated on a non CVS emacs on w32?
>
> Also, as a side note in lieu of a future dragbox package; in a fresh
> environment when evaluating these functions on the two 23.*
> SOFT-MJASON  builds referd above the key bindings on
> image-mode-mode-map of `dragbox-lmb-click-handler' and
> `dragbox-rmb-click-handler' didn't take until after a (require
> 'image-mode). Additionally, I needed a (require 'xml) to get the
> invocation of `xml-print' in `dragbox-update-box' to evaluate.
>
> Just to make sure I also tried evaluating CYD's svg example here:
> (URL `http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg01166.html')
> I know this works on a GNU box but on the w32 systems get:
> => "Invalid image type `svg'"
>
> Any advice as to what needs to be done to get supprot for `svg' on w32?
>
> I look forward to testing the dragbox functions on a GNU box later this evening.
>
> s_P
-- 
Joakim Verona

[-- Attachment #2: dragbox-test.el --]
[-- Type: text/plain, Size: 4150 bytes --]

;;; dragbox-test.el --- dragbox - draw a bounding box interactively

;;; Commentary:
;; draw a bounding box on an image.
;; needs an Emacs with svg support compiled in.

;; Author: Joakim Verona, (C) FSF 2009, GPL

;;; History:
;; 

(require 'image-mode)
(require 'xml)

(if (not (image-type-available-p 'svg))
    (error "No svg available!"))


;;arbitrary image size, for testing
;;; Code:
(setq dragbox-image-width 744)
(setq dragbox-image-height 1052)

;;initial bounding box
(setq dragbox-x1y1 '(0 . 0))
(setq dragbox-x2y2 '(100 . 100))

(setq dragbox-image-url "")

(defun dragbox-start (image-file)
  "Start here with an IMAGE-FILE suitable for svg embedding."
  (interactive "fImage file:")
  
  (get-buffer-create "*dragbox*")
  (switch-to-buffer  "*dragbox*")
  (setq dragbox-image-url (concat "file://" (expand-file-name image-file)))
  (dragbox-update-box-from-state))


(defun dragbox-make-svg-data (x y width height image-url)
  "Return svg describing a image file with a bounding box ontop.
X Y WIDTH HEIGHT describes the box, IMAGE-URL which image to draw on."
  `((svg
         ((xmlns:dc . "http://purl.org/dc/elements/1.1/")
          (xmlns:cc . "http://creativecommons.org/ns#")
          (xmlns:rdf . "http://www.w3.org/1999/02/22-rdf-syntax-ns#")
          (xmlns:svg . "http://www.w3.org/2000/svg")
          (xmlns:xlink . "http://www.w3.org/1999/xlink")
          (xmlns . "http://www.w3.org/2000/svg")
          (width . ,(number-to-string dragbox-image-width))
          (height . ,(number-to-string dragbox-image-height))
          (id . "svg2"))
         (g
          ((id . "layer1"))
          (rect
           ((style . "fill:#cfcfcf;fill-opacity:1")
            (width . ,(number-to-string dragbox-image-width))
            (height . ,(number-to-string dragbox-image-height))
            (x . "0")
            (y . "0")))
          (image ((y . "0")
                  (x . "0")
                  (width . ,(number-to-string dragbox-image-width))
                  (height . ,(number-to-string dragbox-image-height))
                  (xlink:href . ,image-url)
                 ))
          (rect
           ((style . "color:#000000;fill:#000000;fill-opacity:0.5;fill-rule:nonzero;stroke:#000000;stroke-width:1;marker:none;visibility:visible;display:inline;overflow:visible;enable-background:accumulate;stroke-opacity:0.5")
            (id . "dragbox")
            (width . , (number-to-string width) )
            (height . ,(number-to-string height))
            (x . ,(number-to-string x))
            (y . ,(number-to-string y))))
          ))))

(defun dragbox-lmb-click-handler ()
  "Set upper left coords for bounding box."
            (interactive)
            (setq dragbox-x1y1 (dragbox-extract-event-coords last-input-event))
            (dragbox-update-box-from-state)
            )

(defun dragbox-rmb-click-handler ()
  "Set lower right coords for bounding box."
            (interactive)
            (setq dragbox-x2y2 (dragbox-extract-event-coords last-input-event))
            (dragbox-update-box-from-state)
            )

(defun dragbox-extract-event-coords (event)
  "Get the coordinates from click EVENT."
   (caddr(cadr last-input-event))
  )

;;bind the handlers to lmb and rmb
(define-key image-mode-map [down-mouse-1] 'dragbox-lmb-click-handler)
(define-key image-mode-map [down-mouse-2] 'dragbox-rmb-click-handler)


(defun dragbox-update-box (x y width height)
  "Redraw the bounding box, given X Y WIDTH and HEIGHT ontop of the image."
  ;;this implementation doest seem very efficient
  (fundamental-mode)
  (erase-buffer)
  (xml-print (dragbox-make-svg-data x y width height dragbox-image-url))
  (image-mode)
    )

(defun dragbox-update-box-from-state ()
  "Redraw bounding box from global state ontop of image."
  (let*
      ((x1 (car dragbox-x1y1))
       (y1 (cdr dragbox-x1y1))
       (x2 (car dragbox-x2y2))
       (y2 (cdr dragbox-x2y2))
       (w (- x2 x1))
       (h (- y2 y1)))
    (message "(%d %d) (%d %d) w:%d h:%d" x1 y1 x2 y2 w h)
    (dragbox-update-box
     x1
     y1
     w
     h)))

                      


(provide 'dragbox-test)

;;; dragbox-test.el ends here

Re: Drawing in images?

[Lennart Borgman]

On Thu, Sep 17, 2009 at 11:46 PM,  <joakim@verona.se> wrote:
> MON KEY <monkey@sandpframing.com> writes:
>
>> On Wed, Sep 16, 2009 at 3:04 PM,  <joakim@verona.se> wrote:
>>>
>>> Here's an attempt. Its hardly industrial strength, but seems to work.
>>> Test with m-x  dragbox-start, enter an image file name compatible with
>>> svg, I tried png. Then set the corner coords for the box with LMB and RMB.
>>>
>>
>> Joakim thanks for taking a shot at this.  This is very exciting.
>> Unfortunately I can't evaluate. After invoking the `dragbox-start'
>> comman with both .png and .jpg image-file types the  *dragbox* buffer
>> returns some svg data and a message:
>
> Thanks for testing. I added the requires you mention, and cleaned up the
> code a little bit for readability. Still not industrial strength, but
> works here(but I only tested it on a single png file). Looking forward
> to your further comments.
>
>> => "Invalid image type `svg'"


I have added the librsvg-2-2.dll and tried to test this, but it
failed, init-image-library returned nil. Maybe I need to recompile
too?

Re: Drawing in images?

[Juanma Barranquero]

On Fri, Sep 18, 2009 at 00:09, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> I have added the librsvg-2-2.dll and tried to test this, but it
> failed, init-image-library returned nil. Maybe I need to recompile
> too?

C:\emacs\nt> configure --help
Usage: configure [options]
Options:
   --prefix PREFIX         install Emacs in directory PREFIX
  [...etc...]
   --with-svg              use the RSVG library (experimental)

You'll need to provide the appropriate librsvg headers, and use the
--with-svg configure option.

    Juanma

Re: Drawing in images?

[Lennart Borgman]

On Fri, Sep 18, 2009 at 12:46 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Fri, Sep 18, 2009 at 00:09, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>
>> I have added the librsvg-2-2.dll and tried to test this, but it
>> failed, init-image-library returned nil. Maybe I need to recompile
>> too?
>
> C:\emacs\nt> configure --help
> Usage: configure [options]
> Options:
>   --prefix PREFIX         install Emacs in directory PREFIX
>  [...etc...]
>   --with-svg              use the RSVG library (experimental)
>
> You'll need to provide the appropriate librsvg headers, and use the
> --with-svg configure option.


I see, thanks. Could you please tell me a bit more about the headers?
What do I need to do when I use gcc? (Version, extra headers, etc.)

Re: Drawing in images?

[Jason Rumney]

MON KEY wrote:
> Any advice as to what needs to be done to get supprot for `svg' on w32?
>   

You need to install the development packages for most of GTK, Freetype, 
and some other libraries as well as librsvg itself, then configure Emacs 
with --with-svg.  Then, with all the DLLs for the libraries you 
installed in your PATH, and no conflicting DLLs elsewhere in your PATH, 
you can view some SVG images, images with text that has been rotated or 
stretched usually causes a crash deep within the Freetype library or its 
dependencies.

Re: Drawing in images?

[Lennart Borgman]

On Fri, Sep 18, 2009 at 12:56 AM, Jason Rumney <jasonr@gnu.org> wrote:
> MON KEY wrote:
>>
>> Any advice as to what needs to be done to get supprot for `svg' on w32?
>>
>
> You need to install the development packages for most of GTK, Freetype, and
> some other libraries as well as librsvg itself, then configure Emacs with
> --with-svg.  Then, with all the DLLs for the libraries you installed in your
> PATH, and no conflicting DLLs elsewhere in your PATH, you can view some SVG
> images, images with text that has been rotated or stretched usually causes a
> crash deep within the Freetype library or its dependencies.


That sounds very complex. Could you perhaps tell more in detail what
needs to be done?

Re: Drawing in images?

[MON KEY]

While examining dragbox2.el it occurred to me that an alternative way to
set a crop would be to use emacs window... er actually 5 windows!

                                                                 68.
  _________________________________________________________________
 |                             !                     |             |
 | window1                     !                     |    window4  |
 |                             !                     |             |
 |                             !                     |             |
 |                            \|/                    |             |
 |---------------------------------------------------|             |
 |           |                /!\                    |             |
 |           |                 !                     |             |
 |           |          Y-axis !                     |             |
 |           |                 !                     |             |
 |           |                 !                     |             |
 |           |                 !                     |             |
 |           |                 !                     |             |
 |           |                 !                     |             |
 |           |        window5  !                     |             |
 |~~~~~~~~~~>|<~~~~~~~~~~~~~~~~+~~~~~~~~~~~~~~~~~~~~>|<~~~~~~~~~~~~|
 |           |                 !       X-axis        |             |
 |           |                 !                     |             |
 |           |                 !                     |             |
 |           |                 !                     |             |
 |           |                 !                     |             |
 |           |                 !                     |             |
 |           |                 !                     |             |
 |           |                 !                     |             |
 |           |                 !                     |             |
 |           |                \!/                    |             |
 |           |-----------------------------------------------------|
 |           |                /!\                          window3 |
 |           |                 !                                   |
 |           |                 !                                   |
 |           |                 !                                   |
 |   window2 |                 !                                   |
 |___________|_________________|___________________________________|
                                                                 68^


* Assume that the image to be cropped/bounded is in window5.

* Assume that all windows have a ~1-3 pixel border.

* Assume that window1, window2, window3, window4 can _only_ be
expanded contracted
  on the axis indicated.

* Assume that window 5 is the only window that can be
expanded/contracted on both axis.

* Assume use of a library such as Drew Adams' DoReMi or equivalent.

* Assume Y-axis -> Up/Down expansion/contraction

* Assume X-axis -> Left/Right expansion/contraction

Window1 can expand/contract only along the Y-axis
Window2 can expand/contract only along the X-axis
Window3 can expand/contract only along the y-axis
Window4 can expand/contract only along the X-axis

Window5 can expand/contract along both the X-axis and Y-axis.
Window5 can recenter/reset the image along both the X-axis and Y-axis.

Shouldn't `posn-object-width-height', `posn-window', `posn-area' etc.
get one reasonably accurate pixel coardinates for a crop?

If so, doesn't this give us visual feedback without need of external calls, SVG
overlays, GTK wonkery etc.?

Also, a novel idea for doing image rotation using artist.el
as influenced by Unpaper's "Virtual Bar":
(URL `http://unpaper.berlios.de/img/deskew-detail1.png')
(URL `http://unpaper.berlios.de/img/deskew-detail2.png')

Which skews an image against a "Virtual Line" by calculating the skew against
some baseline (x-axis, y-axis, both) i.e. the radian as the virtual line's
deviation from "square".

    Emacs window (preferably in a dedicated frame)
 +--------------------------------------------------------60.
 |                                                         |
 |    +-----------------------------------------------+    |
 |    |                     .                         |    |
 |    |                    /                          |    |
 |    |                   /                           |    |
 |    |                  /                            |    |
 |    |                 /                             |    |
 |    |                /                              |    |
 |    |               /                               |    |
 |    |              /                                |    |
 |    |             / <-Virtual Line                  |    |
 |    |            /                                  |    |
 |    |           /                                   |    |
 |    |          /                                    |    |
 |    |         /                                     |    |
 |    |        /                                      |    |
 |    |       /                                       |    |
 |    |      /                                        |    |
 |    |     /                                         |    |
 |    |    /                                          |    |
 |    |   /                                           |    |
 |    |  .                                            |    |
 |    |                                               |    |
 |    |                                               |    |
 |    |                                               |    |
 |    |                                               |    |
 |    |                                               |    |
 |    |                                               |    |
 |  Y |                                               |    |
 |    |       A Skewed Image (needs rotating)         |    |
 |    +-----------------------------------------------+    |
 |      X                                                  |
 +--------------------------------------------------------60.

s_P

Re: Drawing in images?

[martin rudalics]

 > While examining dragbox2.el it occurred to me that an alternative way to
 > set a crop would be to use emacs window... er actually 5 windows!

The one you sketched in the drawing is not a valid window layout for an
Emacs frame.  Visually, such layouts have at least one "guillotine cut"
on the frame's root window and, recursively, on each of the emanating
subwindows.

martin

Re: Drawing in images?

[MON KEY]

On Tue, Sep 29, 2009 at 1:29 AM, martin rudalics <rudalics@gmx.at> wrote:
> The one you sketched in the drawing is not a valid window layout for an
> Emacs frame.

Hrrmm...  I should have actually verified the sketch.
Even better, now we got Portrait-Format and Landscape-Format!

                 Landscape Format
 +------------------------------------------------53.
 |                        !                         |
 |                        !                         |
 |                        !                         |
 |                       \!/                        |
 |--------------------------------------------------|
 |           | C-x 2;    /!\            |           |
 |           | C-x 2;     !             |           |
 |           | C-x o;     !             |           |
 |           | C-x 3;     !             |           |
 |           | C-x 3;     !             |           |
 |           | C-x o      !             |           |
 |           |            !             |           |
 |           |           \!/            |           |
 |~~~~~~~~~~>|<~~~~~~~~~~~+~~~~~~~~~~~~~|<~~~~~~~~~~|
 |           |           /!\            |           |
 |           |            !             |           |
 |           |            !             |           |
 |           |            !             |           |
 |           |            !             |           |
 |           |            !             |           |
 |           |            !             |           |
 |           |            !             |           |
 |           |            !             |           |
 |           |           \!/            |           |
 |--------------------------------------------------|
 |                       /!\                        |
 |                        !                         |
 |                        !                         |
 |                        !                         |
 +------------------------------------------------53.


                  Portrait Format
 +------------------------------------------------53.
 |           |            !             |           |
 |           |            !             |           |
 |           |           \!/            |           |
 |           |--------------------------|           |
 |           | C-x 3;    /!\            |           |
 |           | C-x 3;     !             |           |
 |           | C-x o;     !             |           |
 |           | C-x 2;     !             |           |
 |           | C-x 2;     !             |           |
 |           | C-x o      !             |           |
 |           |            !             |           |
 |           |           \!/            |           |
 |~~~~~~~~~~>|<~~~~~~~~~~~+~~~~~~~~~~~~>|<~~~~~~~~~~|
 |           |           /!\            |           |
 |           |            !             |           |
 |           |            !             |           |
 |           |            !             |           |
 |           |            !             |           |
 |           |            !             |           |
 |           |            !             |           |
 |           |            !             |           |
 |           |            !             |           |
 |           |            !             |           |
 |           |           \!/	        |           |
 |           |--------------------------|           |
 |           |           /!\            |           |
 |           |            !             |           |
 |           |            !             |           |
 +------------------------------------------------53.


s_P

Drawing in images?

[joakim]

I would like to draw a bounding box inside an image displayed in emacs.

Do I:

 a) use clever already existing way, unknown to me, or

 b) patch my imagemagic patch to support drawing operations within
 images displayed in Emacs, or

 c) non-existing way likelier to be accepted in Emacs, than b)?

The use-case is displaying a scanned image and selecting a region for
OCR, which will result in text that will later be processed in Emacs.
 
-- 
Joakim Verona

Re: Drawing in images?

[Stefan Monnier]

>  a) use clever already existing way, unknown to me, or
>  b) patch my imagemagic patch to support drawing operations within
>  images displayed in Emacs, or
>  c) non-existing way likelier to be accepted in Emacs, than b)?
> The use-case is displaying a scanned image and selecting a region for
> OCR, which will result in text that will later be processed in Emacs.
 
doc-view-set-slice-using-mouse would also like such a thing, so you can
view the rectangle to which you want to crop the document.

I don't think `a' exists (well, you can probably do it by running
ImageMagick somehow and/or construct an XPM or SVG data stream in Elisp,
... pretty messy and likely to be slow).

As for whether `b' or `c' would be preferred, it all depends: in
general, I'd prefer if it worked independently from the backend image
library, so `c' would be the favorite, but I might still prefer a clean
`b' than a messy `c'.
Maybe a good way to do it would be to allow stacking images (in your
case, the bottom one could use any image library, and the top one could
use SVG to draw the region boundary).


        Stefan

Re: Drawing in images?

[joakim]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Maybe a good way to do it would be to allow stacking images (in your
> case, the bottom one could use any image library, and the top one could
> use SVG to draw the region boundary).

Is there a natural way to stack things in Emacs? maybe "composite glyphs"?

>
>
>         Stefan
-- 
Joakim Verona

Re: Drawing in images?

[Stefan Monnier]

>> Maybe a good way to do it would be to allow stacking images (in your
>> case, the bottom one could use any image library, and the top one could
>> use SVG to draw the region boundary).

> Is there a natural way to stack things in Emacs? maybe "composite glyphs"?

I'd think you'll need to define a new value of the `display' property
specifically for that.


        Stefan

Re: Drawing in images?

[Jason Rumney]

Stefan Monnier wrote:
> Maybe a good way to do it would be to allow stacking images (in your
> case, the bottom one could use any image library, and the top one could
> use SVG to draw the region boundary).
>   

For this use case at least, this method seems cleaner than changing the 
actual image, since the overlaid rectangle is transient.  I wonder if 
compose-character has some of the code you need already?

Re: Drawing in images?

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 26 Aug 2009 00:57:17 +0200, joakim@verona.se said:

> I would like to draw a bounding box inside an image displayed in
> emacs.  Do I:

>  a) use clever already existing way, unknown to me

Maybe existing image slicing and box drawing with face can be used for
some simple cases.

(defface inner-box '((t :box (:line-width -1))) "Simple box")

(defun insert-image-with-box (image x y w h)
  (let* ((image-size (image-size image t))
	 (image-width (car image-size))
	 (image-height (cdr image-size)))
    (if (or (<= w 0) (<= h 0) (< x 0) (< y 0)
	    (> (+ x w) image-width) (> (+ y h) image-height))
	(error "Box empty or not contained in the image")
      (when (> y 0)
	(insert-image image nil nil (list 0 0 image-width y))
	(insert (propertize "\n" 'line-height t)))
      (when (> x 0)
	(insert-image image nil nil (list 0 y x h)))
      (insert (propertize " " 'display `((slice ,x ,y ,w ,h) ,image)
			  'face 'inner-box))
      (when (< (+ x w) image-width)
	(insert-image image nil nil (list (+ x w) y (- image-width x w) h)))
      (insert (propertize "\n" 'line-height t))
      (when (< (+ y h) image-height)
	(insert-image image nil nil (list 0 (+ y h)
					  image-width (- image-height y h)))
	(insert (propertize "\n" 'line-height t))))))

;; Turn off font-lock-mode before you try this in *scratch*.
(insert-image-with-box (create-image "splash.png") 50 30 100 150)

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp