the Release Notes need you
Hello, for your info, the following documentation is still missing from the release notes. If you don't add it, others will do it but may miss some things you put in that feature.
* Layer Dialog (joncruz, mental) * details of Remove Overlaps (pjrm) * xfig format (?) is this really implemented? * ODG format (ishmal) * new cursors (scislac)
ralf
Ralf Stephan wrote:
Hello, for your info, the following documentation is still missing from the release notes. If you don't add it, others will do it but may miss some things you put in that feature.
- Layer Dialog (joncruz, mental)
- details of Remove Overlaps (pjrm)
- xfig format (?) is this really implemented?
- ODG format (ishmal)
- new cursors (scislac)
ralf
Yes, I definitely will, as soon as I sleep a bit. I need it because I spent the last couple of days totally rewriting the SIOX stuff, and set up a testing and debug project for it independent of Inkscape.
So now a simple initial capability is available, where one marks the foreground. Everything else is Siox's CERTAIN_BACKGROUND_CONFIDENCE. This means that the unmarked colors will be analyzed to create a color signature for the background. The image will be subsequently analyzed and all of the contiguous areas of background color will be removed.
Siox also has a CERTAIN_FOREGROUND_CONFIDENCE markup which can improve results, but I still need to think of a way to mark that on Inkscape.
Here is a simple example: http://inkscape.org/win32/siox/howto.svg
And a patch to this morning's svn (at the /src level) to enable this is here, if anyone wants to try it: http://inkscape.org/win32/siox/siox.patch
Please give it a try. I'm going to sleep now ;-)
bob (ishmal)
Bob Jamison wrote:
And a patch to this morning's svn (at the /src level) to enable this is here, if anyone wants to try it: http://inkscape.org/win32/siox/siox.patch
This build has it: http://inkscape.modevia.com/win32/Inkscape0606030846.zip
bob
Bob,
I still haven't tested it myself, but in your howto.svg, the dark areas of the horse are rendered light, so it looks somewhat like a negative. This looks like a bug to me. Do you think you can fix it?
bulia byak wrote:
Bob,
I still haven't tested it myself, but in your howto.svg, the dark areas of the horse are rendered light, so it looks somewhat like a negative. This looks like a bug to me. Do you think you can fix it?
I have no idea how you notice these details, but yes, you were right. Because the other image types in trace don't use alpha, I was ignoring it. And since my test images didn't have alpha, I didn't see it.
The fix is in the patch tracker, and here is the corrected example: http://inkscape.org/win32/siox/howto.svg
thanks!
bob
Bob Jamison wrote:
The fix is in the patch tracker, and here is the corrected example: http://inkscape.org/win32/siox/howto.svg
Oh this is pretty awesome. Not sure if you've written up anything for the tutorials on this but here are some questions that could go into it. 1) how does the svg file size compare ? 2) does it change much if potracing from png, gif, jpg ? 3) relative time to convert ? 4) once you have the svg image (ie the horse) is there a way to better blend the color groups (it's a little "blocky") - maybe like specifying the line as thicker and a gradient color ?
Hi!
jtaber wrote:
Bob Jamison wrote:
The fix is in the patch tracker, and here is the corrected example: http://inkscape.org/win32/siox/howto.svg
Oh this is pretty awesome. Not sure if you've written up anything for the tutorials on this but here are some questions that could go into it.
- how does the svg file size compare ?
I would say that since you will be tracing a smaller sample of the image, the svg size should be smaller. However, as I've always said, tracing has never been intended to create a finished product. Its purpose is to generate curves for the user to further manipulate.
- does it change much if potracing from png, gif, jpg ?
Not at all. It starts with the same pixbuf in memory that normal tracing uses, then feeds a resulting pixbuf to the other filters for processing.
- relative time to convert ?
It has been adding about 5 to 15 seconds to trace times. Yes, it's slow, but it's a very CPU-intensive operation. Hey, this is high-tech image recognition stuff here. :-) But yes, we will definitely work on reducing the times, same as we (especially Mr. Selinger, to whom we owe so much for Potrace in the first place) reduced that of normal tracing.
- once you have the svg image (ie the horse) is there a way to better
blend the color groups (it's a little "blocky") - maybe like specifying the line as thicker and a gradient color ?
Just try tweaking the other filter settings to get what you want. Notice that the example used only 8 colors. But again, I state the #1 item. The trace is not intended to be a final product. Besides, trying to create a photo-perfect image trace would be a silly waste of time. Tracing is supposed to be an exercise in information reduction.
This was only completed at the last minute here, so use it, try to break it, etc. I hope that people find it useful.
bob
On Mon, Jun 05, 2006 at 01:56:48PM -0500, Bob Jamison wrote:
This was only completed at the last minute here, so use it, try to break it, etc. I hope that people find it useful.
This is an awesome feature, and it's great to see it getting in. One thought though -- since it's come in pretty late, and probably won't get sufficient testing/bug fixing prior to release, could you configure it as an experimental feature (i.e., add a preference item to turn it on with a clear warning that it's experimental, and have it off by default)? This way, users will still be able to access it, but if there are problems it won't generate a flurry of unnecessary bug reports and questions. We've had really good luck with this approach for other new experimental features in the past, so it'd probably be helpful here too.
(We've had a few people with questions/confusion on the irc channel, due to long processing times, etc. and some concern over stability due to how new it is, but we all thought it'd be better to have it listed as experimental than to have to leave it out of the release.)
Bryce
On 6/5/06, Bryce Harrington <bryce@...961...> > This is an awesome feature, and it's great to see it getting in. One
thought though -- since it's come in pretty late, and probably won't get sufficient testing/bug fixing prior to release, could you configure it as an experimental feature (i.e., add a preference item to turn it on with a clear warning that it's experimental, and have it off by default)?
No need to do it that complex, IMHO. Just add "(experimental)" to the label of the checkbox in the Trace dialog. There's plenty of space there for it.
bulia byak wrote:
On 6/5/06, Bryce Harrington <bryce@...961...> > This is an awesome feature, and it's great to see it getting in. One
thought though -- since it's come in pretty late, and probably won't get sufficient testing/bug fixing prior to release, could you configure it as an experimental feature (i.e., add a preference item to turn it on with a clear warning that it's experimental, and have it off by default)?
No need to do it that complex, IMHO. Just add "(experimental)" to the label of the checkbox in the Trace dialog. There's plenty of space there for it.
I think if the issues are mentioned in a tutorial (which most people will hopefully first read) then things like a long processing time are not a problem. In the next few days I'm going to try to get the new tarball running and try this out on some rasters - I'll write up a few paragraphs from the user side - if that makes it to a tutorial in this version fine, if not it can go to the wiki.
On Mon, 5 Jun 2006, jtaber wrote:
bulia byak wrote:
On 6/5/06, Bryce Harrington <bryce@...961...> > This is an awesome feature, and it's great to see it getting in. One
thought though -- since it's come in pretty late, and probably won't get sufficient testing/bug fixing prior to release, could you configure it as an experimental feature (i.e., add a preference item to turn it on with a clear warning that it's experimental, and have it off by default)?
No need to do it that complex, IMHO. Just add "(experimental)" to the label of the checkbox in the Trace dialog. There's plenty of space there for it.
Hopefully that could be done using two seperate strings so translators do not need to retranlsate the lable when the experimental part of the lable bit is removed.
I think if the issues are mentioned in a tutorial (which most people will hopefully first read) then things like a long processing time are
Safer and more likely to assume most people will not read the documentation.
On 6/5/06, Bob Jamison <rwjj@...127...> wrote:
bulia byak wrote:
Bob,
I still haven't tested it myself, but in your howto.svg, the dark areas of the horse are rendered light, so it looks somewhat like a negative. This looks like a bug to me. Do you think you can fix it?
I have no idea how you notice these details, but yes, you were right. Because the other image types in trace don't use alpha, I was ignoring it. And since my test images didn't have alpha, I didn't see it.
The fix is in the patch tracker, and here is the corrected example: http://inkscape.org/win32/siox/howto.svg
The howto says: "2. Cover desired foreground". Could it possibly be reworded to "Draw a closed path around object in foreground" or something like that? Same applies to hint above "SIOX" in Trace dialog.
Alexandre
On 6/6/06, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
The howto says: "2. Cover desired foreground". Could it possibly be reworded to "Draw a closed path around object in foreground" or something like that? Same applies to hint above "SIOX" in Trace dialog.
This really must be made part of the Tracing tutorial. Can someone please do this?
Alexandre Prokoudine wrote:
The howto says: "2. Cover desired foreground". Could it possibly be reworded to "Draw a closed path around object in foreground" or something like that? Same applies to hint above "SIOX" in Trace dialog.
Not really. Determining what is selected is done by using the NR::Arena stuff to render the shape over the bitmap. This way, the fill rule can be borrowed to determine what is in or out of the shape. So "covering" or "obscuring" is actually what is needed to determine what parts of the image are background and which are not. Just drawing a line around it is not enough. But there probably is a better way to say that.
I agree, the selection mechanism needs to be improved. In addition to designating what is background, we need to provide the option to designate what is foreground. This will greatly help the algorithm decide how the remaining regions attract to either foreground or background.
Look at the siox.org page, middle image, to see what I mean. The blue-marked areas are "certain background", meaning that they will certainly not be in the final image. The green-marked part is "certain foreground" meaning that it certainly will be in the final image. The regions between the two will be analyzed to determine which way they will go.
Right now, we are only marking "certain background" by selecting the part we want. Everything else is background. This PDF from the siox.org site has a lot of good examples about what this means: http://www.siox.org/downloads/tr-b-05-07.pdf
bob
On 6/3/06, Bob Jamison <rwjj@...127...> wrote:
And a patch to this morning's svn (at the /src level) to enable this is here, if anyone wants to try it: http://inkscape.org/win32/siox/siox.patch
Maintainers, I haven't yet tested this, but unless it's unusably buggy, I think this should go into 0.44. It's certainly a killer feature :)
--- bulia byak <buliabyak@...400...> wrote:
On 6/3/06, Bob Jamison <rwjj@...127...> wrote:
And a patch to this morning's svn (at the /src level) to enable this is here, if anyone wants to try it: http://inkscape.org/win32/siox/siox.patch
Maintainers, I haven't yet tested this, but unless it's unusably buggy, I think this should go into 0.44. It's certainly a killer feature :)
Just tested this build on XP with SP2, couldnt find any problems with the trace stuff, definitely an interesting feature.
Cheers
Sim
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Jun 3, 2006, at 3:44 AM, Bob Jamison wrote:
And a patch to this morning's svn (at the /src level) to enable this is here, if anyone wants to try it: http://inkscape.org/win32/siox/siox.patch
Please give it a try. I'm going to sleep now ;-)
Go ahead and toss it in the patch tracker whenever it's ready to add in.
That way we won't forget it... and also SF will get to track our activity better. :-)
participants (9)
-
Alan Horkan -
Alexandre Prokoudine -
Bob Jamison -
Bryce Harrington -
bulia byak -
John Cliff -
Jon A. Cruz -
jtaber -
Ralf Stephan