Selected Object Properties Table fields

[isolver]

Right now the fields that are shown in the properties table (below the segment tree) are very arbitrary and not thought through at all. @Mark-Torrance can you give some input on what you think should be displayed in the properties table for a segment, a category (could be same as segment), and a 'selection' when that is added. Again, the selection 'segment' could display the same fields as a segment. The Q is, what should those fields be for the properties to be useful?

[Mark-Torrance]

Can I choose anything from the (current) segment report? (by which I mean this #30)

[isolver]

Yup, other than if what is being displayed is the 'selection region info' as no node in tree is selected (yet to implement this though).

• For segments, it is easy to also show any info you want about parent segment or children of current segment.
• It would also be easy to report the number of 0 pressure samples within a segment if that is of any interest.
• Was also wondering about some 1st level stats like min / max / average
  • non zero sample intervals within a segment
  • same regardless of pressure data value
  • pressure stats for the segment
  • ....

Each is 10 minutes at most to add to both the segment report and the segment properties table as the data is there, or the already masked numpy array is there so it is just a matter of calling numpy functions on the array to get the stats.

On Fri, Apr 17, 2015 at 8:37 AM, Mark-Torrance notifications@github.com wrote:

Can I choose anything from the (current) segment report?

— Reply to this email directly or view it on GitHub https://github.com/isolver/MarkWrite/issues/45#issuecomment-93977668.

[Mark-Torrance]

Ok. How about (in order of complexity):

• Name, ID, duration (in ms), start and end times, point count
• parent path (because not always obvious from the tag tree view if very many tags at one level)
• count of periods when pressure < 0 where period == set of consecutive samples
• sum, mean, max, sd, duration (ms) for periods when pressure pressure < 0
• preceding pen-lift duration (time (ms) between immediately preceding sample with pressure > 0 and segment start)
• preceding pause (time to first immediately previous sample S for which S.xy != S-1.xy and S.pressure > 0 and S-1.pressure > 0. i.e. time to the end of the last inking pen move)
• count, mean duration, max duration of pauses in segment where pause == series of consecutive samples with total duration of >=t which are non-inking (i.e. pen is either static or lifted), for t = 500, t = 1000, t = 2000, t = 3000

This last is what many users will be looking for and something that I'd planned to do. If it's easy then it would be fantastic if your could implement it, but I realise it's more complex than the sort of thing that you imagined. Please don't devote loads of time to it.

When we have pressure data then we'll need a more sophisticated definition of pause (or actually different pause-types), but this will do for now.

[isolver]

@Mark-Torrance , Can you please clarify some of these segment properties?

sum, mean, max, sd, duration (ms) for periods when pressure pressure < 0

Did you mean when pressure pressure > 0, or == 0,; I do not think pen pressure will ever be < 0 will it? I have assumed that pressure is an unsigned value.

• preceding pen-lift duration (time (ms) between immediately preceding sample with pressure > 0 and segment start)
• preceding pause (time to first immediately previous sample S for which S.xy != S-1.xy and S.pressure > 0 and S-1.pressure > 0. i.e. time to the end of the last inking pen move)

So the difference between these two is that the second one filters out a possible series samples where pressure was > 0 and pen pos was equal, that the first one does not?

count, mean duration, max duration of pauses in segment where pause == series of consecutive samples with total duration of >=t which are non-inking (i.e. pen is either static or lifted), for t = 500, t = 1000, t = 2000, t = 3000

What do you when for t = 500, t = 1000, ...? Do you mean relative to the segments start time, bin the segment duration into different lengths, up to segment duration??

[isolver]

I should remove the TBD valued field at least for now

[Mark-Torrance]

Ah, I just wrote a long response to this which I seem to have discarded. Basically, for now I think I'll write a stand-alone program that processes that raw input file and the segment report as it now stands. This means that I can add in more variables as I need them rather than relying on them being generated in the segment report. If there are some obvious variables from this post-processing that would be useful to all users (pause counts within segments, for example) these can be added to the segment report in Release 2.

[isolver]

So here is how the segment properties stands right now.

• [ ] Note: A subset of these should also be applied to the selection region properties table dict as well at some point.

[Mark-Torrance]

I think that's good.