Fwd: OpenRaster and non destructive raster effects on Inkscape
![](https://secure.gravatar.com/avatar/e1ef55136ae45d648254935a18e9acb7.jpg?s=120&d=mm&r=g)
Sometimes we decide to change the brightness, contrast, saturation or other things on a raster image, inside the SVG file.
The OpenRaster proposal ( http://pippin.gimp.org/OpenRaster ) is a good ideia for some things and for a extending possibilities with raster in inkscape.
With a initial suport of OpenRaster on inkscape we can have special controls for change raster properties whitout to destroy the original raster data.
"Hey Boss... you do not want a lot of contrast? Ok! I don't lose the original image." (Click on menu "object > raster > edit properties") ;-D (easier then re-open on GIMP)
How can it works?
The inkscape can have a suport for the OpenRaster format and allow the OpenRaster name space on the SVG XML.
When we try to change the contrast on a raster image the XML changes from: <image xlink:href="img.jpg" />
to this: openraster:image openraster:layers <openraster:brightness-contrast contrast='1.4'/> <openraster:layer src='img.jpg'/> </openraster:layers> </openraster:image>
We can use the menu "object > raster > aplay raster changes" and the OpenRaster block comes to a svg:image. It will help to send the SVG file to other softwares.
With this implementation effects will can handle this raster properties too.
The <animate> can be used on the 0.48 to animate raster properties too. (extending more the SVG standard) ;-) May the Mozilla team implement that too?
What you think? Aurium
![](https://secure.gravatar.com/avatar/dc940f48c5635785f32941f1fbe6b601.jpg?s=120&d=mm&r=g)
On May 8, 2007, at 6:29 PM, Aurélio A. Heckert wrote:
The inkscape can have a suport for the OpenRaster format and allow the OpenRaster name space on the SVG XML.
When we try to change the contrast on a raster image the XML changes from:
<image xlink:href="img.jpg" />
to this: openraster:image openraster:layers <openraster:brightness-contrast contrast='1.4'/> <openraster:layer src='img.jpg'/> </openraster:layers> </openraster:image>
We can use the menu "object > raster > aplay raster changes" and the OpenRaster block comes to a svg:image. It will help to send the SVG file to other softwares.
Well... the first problem is that SVG only requires software to support PNG, JPEG and SVG, so we really can't have <image> tag linked to anything else and still stay universal.
The second, and larger, problem is that switching from using standard SVG <image> conventions to some custom namespace will make the SVG file non-standard. That is, if we send the SVG over to an arbitrary program that handles SVG, it will not display correctly unless the destructive change back to <image> has taken place.
To balance that we could just have the linked <image> updated whenever the openraster parts are updated, but that looses a bit.
![](https://secure.gravatar.com/avatar/214fe9a0ecb4aed8994e8618ade6f5a8.jpg?s=120&d=mm&r=g)
Jon A. Cruz wrote:
On May 8, 2007, at 6:29 PM, Aurélio A. Heckert wrote:
The inkscape can have a suport for the OpenRaster format and allow
the OpenRaster name space on the SVG XML.
When we try to change the contrast on a raster image the XML
changes from:
<image xlink:href="img.jpg" />
to this:
<openraster:layers> <openraster:brightness-contrast contrast='1.4'/> <openraster:layer src='img.jpg'/> </openraster:layers>
</openraster:image>
We can use the menu "object > raster > aplay raster changes"
and the OpenRaster block comes to a svg:image. It will
help to send the SVG file to other softwares.
Well... the first problem is that SVG only requires software to support PNG, JPEG and SVG, so we really can't have <image> tag linked to anything else and still stay universal.
The second, and larger, problem is that switching from using standard SVG <image> conventions to some custom namespace will make the SVG file non-standard. That is, if we send the SVG over to an arbitrary program that handles SVG, it will not display correctly unless the destructive change back to <image> has taken place.
To balance that we could just have the linked <image> updated whenever the openraster parts are updated, but that looses a bit.
Isn't there a <foreignObject> tag or something like that which is analogous to the <object> tag in HTML?
Tim Rowley (the other <tor>) from IBM is the Mozilla guy who worries about the problems with SVG in a browser, with all of its issues. Maybe he would be the best guy to ask.
bob
![](https://secure.gravatar.com/avatar/e1ef55136ae45d648254935a18e9acb7.jpg?s=120&d=mm&r=g)
On 5/8/07, Jon A. Cruz <jon@...18...> wrote:
On May 8, 2007, at 6:29 PM, Aurélio A. Heckert wrote:
(...) When we try to change the contrast on a raster image the XML changes from:
<image xlink:href="img.jpg" />
to this: openraster:image openraster:layers <openraster:brightness-contrast contrast='1.4'/> <openraster:layer src='img.jpg'/> </openraster:layers> </openraster:image>
We can use the menu "object > raster > aplay raster changes" and the OpenRaster block comes to a svg:image. It will help to send the SVG file to other softwares.
Well... the first problem is that SVG only requires software to support PNG, JPEG and SVG, so we really can't have <image> tag linked to anything else and still stay universal.
Ok. :-) No OpenRaster link on <image>. Like i think.
The second, and larger, problem is that switching from using standard SVG <image> conventions to some custom namespace will make the SVG file non-standard. That is, if we send the SVG over to an arbitrary program that handles SVG, it will not display correctly unless the destructive change back to <image> has taken place.
Yes. You are right. By that i propose the menu "object > raster > aplay raster changes" But you give a better idea...
To balance that we could just have the linked <image> updated whenever the openraster parts are updated, but that looses a bit.
Thanks! You help the idea! Change on my proposal:
The svg:image and openraster:image still existing forever. Like that: <image id="image123" xlink:href="data:image/png;base64..." inkscape:orlink="#or123" /> <openraster:image id="or123"> openraster:layers <openraster:brightness-contrast contrast='1.4'/> <openraster:layer src='img.jpg'/> </openraster:layers> </openraster:image>
When a image is selected the Inkscape knows the OpenRaster reference and allow the user to change the OpenRaster defs by some "Raster Properties" window. When it is updated, a new PNG image data is updated on <images>'s xlink:href attribute.
Well. The designer boss will be happy and the SVG will still viewable for other programs. :-)
Thanks, Aurium
![](https://secure.gravatar.com/avatar/dc940f48c5635785f32941f1fbe6b601.jpg?s=120&d=mm&r=g)
On May 9, 2007, at 8:07 AM, Aurélio A. Heckert wrote:
Thanks! You help the idea! Change on my proposal:
The svg:image and openraster:image still existing forever. Like that: <image id="image123" xlink:href="data:image/png;base64..." inkscape:orlink="#or123" /> <openraster:image id="or123"> openraster:layers <openraster:brightness-contrast contrast='1.4'/> <openraster:layer src='img.jpg'/> </openraster:layers> </openraster:image>
When a image is selected the Inkscape knows the OpenRaster reference and allow the user to change the OpenRaster defs by some "Raster Properties" window. When it is updated, a new PNG image data is updated on <images>'s xlink:href attribute.
Well. The designer boss will be happy and the SVG will still viewable for other programs. :-)
OK. This is sounding good, and close to how I would imagine the workflow to function.
First of all we have three files involved. 1) the SVG file. 2) the 'result' image file that gets published (PNG or JPEG) 3) the 'source' image file that is original content and is preserved.
Although adding some openraster inline at some point might be good, at this point in time I think external support might work well enough. That is, we could get a similar workflow by having just an extra attribute to specify the 'source' image. Then when the user right-clicks on the image, he well be presented an "Edit original" option in the menu. This then would allow an openraster image to be used for the source, and to be manipulated from within an openraster program. The way I see it, the workflow would be close to embedding openraster directly.
*However*
We do happen to have a Summer of Code project being done by Christopher Brown that aims to add some raster functionality to Inkscape itself. I believe that the proposed support would benefit from the option to have a source image to allow for non-destructive editing.
A second thing would be to craft the SoC implementation so that it could easily be extended to use openraster at some point in the future when there is a viable library for it. (The subject came up this past weekend at LGM, and at the moment there is not yet a library for it. Nor does it make sense for them to start with a library, since Krita and Gimp have such different internals, etc.)
participants (3)
-
Aurélio A. Heckert
-
Bob Jamison
-
Jon A. Cruz