Loading ...
Sorry, an error occurred while loading the content.

Question #6 : jig-saw puzzles

Expand Messages
  • david dailey
    My list of unanswered questions has been given a more lasting home. If you have not enough troubles of your own, please see
    Message 1 of 2 , Jan 5, 2006
    View Source
    • 0 Attachment
      My list of unanswered questions has been given a more lasting home.
      If you have not enough troubles of your own, please see
      http://srufaculty.sru.edu/david.dailey/svg/svg_questions.htm) for
      things that have been troubling me.

      Of particular interest to me of late has been #6 concerning jig-saw
      puzzle carving. Here's what I have figured out:


      6. To make a jig-saw puzzle using SVG, one may

      a) chop up an image into little movable chunks using numerous
      clipPaths applied to numerous copies of an image (see for example,
      <http://srufaculty.sru.edu/david.dailey/svg/clips2.svg>http://srufaculty.sru.edu/david.dailey/svg/clips2.svg).
      The problem is that this appears to use lots and lots of RAM and bogs
      down when the number of rows and columns gets large. For those using
      IE/ASV see also http://marble.sru.edu/~ddailey/svg/clipembed16.html
      in which the loci of clipPaths are permutable according to a
      user-supplied string of less than rows x cols characters.

      b) <http://srufaculty.sru.edu/david.dailey/svg/later/offsets7.svg>use
      feOffset's and feTile's to slice an image (be prepared to wait a
      while for it to render). I didn't see any easier way to grab the
      parts I wanted to move than this. It is way too time-consuming (I
      assume this is processor rather than RAM related) to be practical on
      a large scale.

      c) build a checkerboard of red-scale values underneath the image and
      then distort the image using <feDisplacementMap> and the
      red-channel. See
      <http://srufaculty.sru.edu/david.dailey/svg/later/displace2.svg>attempt1
      or
      <http://srufaculty.sru.edu/david.dailey/svg/later/displace4.svg>attempt2
      by way of illustration. The approach looks like it will be fast and
      generalize easily to large images with lots of slices. The hassle is
      that the exact distance by which pixels are moved, while clearly
      related to the displacement's scale attribute and the red-scale value
      of the underlying map, seem not to be entirely predictable (see
      <http://srufaculty.sru.edu/david.dailey/svg/later/displace7.svg>attempt3).
      The <http://www.w3.org/TR/SVG11/filters.html#feDisplacementMap>W3C
      spec actually spells out how the pixel loci will move, so maybe I'm
      just misreading it. The other hassle, of course, is that this uses
      filters and not many browsers are currently handling it.

      Is there an easier way? Can I somehow just grab the pixels out of a
      rectangular section of a bitmap in SVG and move (just) them around? I
      think I may just be missing something key in the SVG tool set.


      [Non-text portions of this message have been removed]
    • Jeff Schiller
      David, I m not an expert on this, but I ve been wondering about it myself. The way I would conceive of it being would be like this:
      Message 2 of 2 , Jan 6, 2006
      View Source
      • 0 Attachment
        David,

        I'm not an expert on this, but I've been wondering about it myself.
        The way I would conceive of it being would be like this:

        <svg ...>
        <defs>
        <clipPath id="shape1"... />
        <clipPath id="shape2"... />
        <clipPath id="shape3"... />
        <clipPath id="shape4"... />
        <image id="myImage" xlink:href="foo.png".../>
        </defs>
        <use id="piece1" clipPath="url(#shape1)" xlink:href="url(#myImage)".../>
        <use id="piece2" clipPath="url(#shape1)" xlink:href="url(#myImage)".../>
        <use id="piece3" clipPath="url(#shape2)" xlink:href="url(#myImage)".../>
        <use id="piece4" clipPath="url(#shape2)" xlink:href="url(#myImage)".../>
        <use id="piece5" clipPath="url(#shape3)" xlink:href="url(#myImage)".../>
        ...
        </svg>

        I'm not positive I've got the above right, but it seems to me that if
        you can do the above then SVG implementations don't NECESSARILY have
        to make full copies of the entire raster image if they're efficient
        enough. They could parse it, determine the pixel area that's included
        and make a copy of that region only.

        Unfortunately, at least Firefox uses full copies for its <use>
        elements (as far as I remember). I don't know about Adobe or Opera.
        I guess this is a "wait-until-the-implementations-catch-up" type of
        problem?

        Regards,
        Jeff

        --- In svg-developers@yahoogroups.com, david dailey
        <david.dailey@s...> wrote:
        >
        > My list of unanswered questions has been given a more lasting home.
        > If you have not enough troubles of your own, please see
        > http://srufaculty.sru.edu/david.dailey/svg/svg_questions.htm) for
        > things that have been troubling me.
        >
        > Of particular interest to me of late has been #6 concerning jig-saw
        > puzzle carving. Here's what I have figured out:
        >
        >
        > 6. To make a jig-saw puzzle using SVG, one may
        >
        > a) chop up an image into little movable chunks using numerous
        > clipPaths applied to numerous copies of an image (see for example,
        >
        <http://srufaculty.sru.edu/david.dailey/svg/clips2.svg>http://srufaculty.sru.edu/david.dailey/svg/clips2.svg).

        > The problem is that this appears to use lots and lots of RAM and bogs
        > down when the number of rows and columns gets large. For those using
        > IE/ASV see also http://marble.sru.edu/~ddailey/svg/clipembed16.html
        > in which the loci of clipPaths are permutable according to a
        > user-supplied string of less than rows x cols characters.
        >
        > b) <http://srufaculty.sru.edu/david.dailey/svg/later/offsets7.svg>use
        > feOffset's and feTile's to slice an image (be prepared to wait a
        > while for it to render). I didn't see any easier way to grab the
        > parts I wanted to move than this. It is way too time-consuming (I
        > assume this is processor rather than RAM related) to be practical on
        > a large scale.
        >
        > c) build a checkerboard of red-scale values underneath the image and
        > then distort the image using <feDisplacementMap> and the
        > red-channel. See
        >
        <http://srufaculty.sru.edu/david.dailey/svg/later/displace2.svg>attempt1
        > or
        >
        <http://srufaculty.sru.edu/david.dailey/svg/later/displace4.svg>attempt2
        > by way of illustration. The approach looks like it will be fast and
        > generalize easily to large images with lots of slices. The hassle is
        > that the exact distance by which pixels are moved, while clearly
        > related to the displacement's scale attribute and the red-scale value
        > of the underlying map, seem not to be entirely predictable (see
        >
        <http://srufaculty.sru.edu/david.dailey/svg/later/displace7.svg>attempt3).

        > The <http://www.w3.org/TR/SVG11/filters.html#feDisplacementMap>W3C
        > spec actually spells out how the pixel loci will move, so maybe I'm
        > just misreading it. The other hassle, of course, is that this uses
        > filters and not many browsers are currently handling it.
        >
        > Is there an easier way? Can I somehow just grab the pixels out of a
        > rectangular section of a bitmap in SVG and move (just) them around? I
        > think I may just be missing something key in the SVG tool set.
        >
        >
        > [Non-text portions of this message have been removed]
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.