Personal tools
  • We're Hiring!

You are here: Home Community Minutes Conference Calls 2011 2011-10-25 Tuesday Meeting

2011-10-25 Tuesday Meeting

Attending: Mark Hiner (presenting), Andrew, Carlos, Melissa, Josh (notes), Jean-Marie, Ola (notes), Will, Jason, Colin, Emma, Chris, Scott, Curtis

Agenda

Remember: Agenda must be complete (with estimated times) on the day before the meeting. Any additions after that must go at the bottom (AOCB)

  1. Accepting minutes from last meeting

  2. Matters Arising (<10 mins)

    • Put in action points and PENDING items from last Thursday's meeting.
    • Jason: look into meeting room issues
    • Emma: invite knime and icy to meeting (addresses from Jean-Marie)
    • HIC: presentation on Nov. 1
    • Josh: create runAsAdmin ticket DONE ticket 7055
    • Josh: 4016 and 4017 turn to bug tickets. DONE ticket 7056
  3. SCIFIO Presentation: Mark Hiner's presentation (45 mins)

  4. Any other business (<5 mins)

Attending

  • Mark Hiner (presenting), Andrew, Carlos, Melissa, Josh (notes), Jean-Marie, Ola (notes), Will, Jason, Colin, Emma, Chris, Scott, Curtis

Notes

  • Accepting minutes from last meeting (started 14:33)
    • Accepted
  • Matters Arising (<10 mins)
    • Put in action points and PENDING items from last Thursday's meeting.
    • Jason: look into meeting room issues
      • Room is reserved for lunch.
    • Emma: invite knime and icy to meeting (addresses from Jean-Marie)
      • Emma: Done, didn’t hear anything back from (Fabrice)
      • Jason: biologists are amenable. 9th Afternoon or 10th Morning (e.g. Michael Porter)
      • Will: what? Knime developers helping to build a graphical workflow for the biologists
    • Presentations
      • HIC Planned Nov. 1
      • Presentation on movies 27 Nov.
        • Colin has watched 65 movies! (Didn’t watch the 2.3 movies)
    • Josh: create runAsAdmin ticket DONE ticket 7055
    • Josh: 4016 and 4017 turn to bug tickets. DONE ticket 7056
      • According to 2 tickets above there are some minor things has to be done especially on Windows
  • SCIFIO Presentation: Mark Hiner's presentation (45 mins) (started 14:39)
    • Jason: thank you for the presentation.
    • Chris: One of the problems we are going to have is if there are so few classes in Scifio. Things leak quickly into core. What have you thought about how to handle that?
      • Mark:So (in doc) these are some core formats (AVI, BMP, DICOM, EPS, GIF, …, TIFF, ...), we are going to do the conversion
      • Curtis: you could checkout scifio branch in loci. Currently, all packages are the same so there’s just a new jar dependency.
      • Curtis: should be able to prevent things leaking into core if we have dynamic discovery (sezpoz) as long as the right hooks are in place (e.g. codecs, etc.). The compression in BioFormats is another example
      • Chris: you are talking that core readers being part of scifio and also you are talking that ome-xml be part of plugin.
      • Curtis: to clarify, that list (above) is a union of scifio and the ome layer which provides translation from scifio metadata to ome. In Sample Implementation slide layers are shown how this will look like.
    • Chris: I am thinking about a way we are going to approach this. Is your intention to have this all interface driven but provide Abstract classes as well?
      • Curtis: Should we make a scifio cored another lib? scifio-png? Draw these at dependency lines. E.g. POI-based formats, etc.
      • Chris: if we want to be interface driven that is the right approach to take.
      • Curtis: do want to keep scifio-core slim, but already somethings which could be pulled out. More jars aren’t really bad, as long as you provide the option to bundle the jars.
      • J-M: there is a licencing question. If you combine jars, then the license on the combined jar is different.
      • Curtis: Proprietary formats are copy-left. We should always discuss and agree with the such and such format. I still see there will be 3 sides. Bioformat is copy left ome-xml is … and scifio is something to discuss. If ome-xml is permissively licensed, then we can make ome-xml really easy to use.
      • Jason: from a technical and philosophical perspective, we really try to drive open formats.
    • Chris: looking at Marks’ timeline
      • We don’t know when 4.4 will be released, but likely that it will be before May 2012 (The scifio timeline is fairly ambitious)
      • What is this targeted at? (For releasing; OMERO is heavily dependent on Bio-Formats)
      • We have a extensive testing pattern to use. Embarking on this will required extensively validating against each file format.
      • This is more than a one person job, especially on metadata validation.
      • Curtis: the most urgent thing is that which is labelled “NOW”. Agree that we like the split and redo the license so it can go into imagej. (Just added a new jar) Will keep the old classes in a deprecated package, so code should just compile.
      • The hardest part what could not be automated we will do manual validation.
      • Chris: I want to make sure we have time and resources to do it and do not put us in trouble.
      • Curtis: this is a timeline for Mark’s time on the project. Even if we don’t meet all the goals, it won’t be the end of the world. No one’s specifically asking for this, so we can achieve it as we need. When Mark leaves, the question will be who’s going to continue the work.
    • Jason: if this is directed to imagej2 goals, that is fine. But the value of testing has been pretty clearly demonstrated. Couldn’t this lead us somewhere which is too fractured?
      • Curtis: for me the biggest issue is having a very long running branch. But the code will be the same. Though one is never sure what the community is going to flip-out about.
      • Chris: is this good idea to leave loci classes around and test both stacks? You have to test two stacks.
      • Curtis: Deprecation is a process. We can re-use old tests, while writing new ones.
    • Melissa: we need to address the question of how to make this easier for external users.
      • Update our examples, upgrade the documentation and not let this hurt for other people
      • Chris: reticent to have a branch that runs for 6-7 months, and the merge burden. Are we thinking to merge some this things earlier or is bad idea?
      • Curtis: can see both sides as well. November will be initial refactoring. If we can address shortcomings, then we can merge.
      • New interfaces will popup in the new jar, some will be use some not.
      • Jason: back to what Melissa said, it has to be bullet-proof.
      • Chris: comes down to making sure we know early that we have a merge point. e.g. 6 PFFs for the merge, then we have plenty of time to test. Having the resources is not a problem, but we need to think about planning them.
      • Curtis: I would think we need to stick to the old top-level bioformat’s API. e.g. ImageReader can call into ZeissReader which delegates. That’s fine. Then once we got first merge point done we can send to list question what (PFFs) we are going to do next.
      • Chris: we do not need to prioritise the list of formats. Lets do it in iterative fashion.
      • Jason: I would recommend Mark to ask Melissa what she needs. This will be very important on so many fronts.
      • Melissa: I have mentioned it before to everyone, but as much as possible we need to keep conversations public or at least on nitpick. In terms of coding-style, don’t really care as long as it’s consistent. What’s currently in the branch is not consistent.
      • Curtis: could certainly send to ome-devel.
      • Jason: Just keep in mind discussing issues a head of time, because it will make a big impact of the whole project and affect community.
      • Josh: There were good example of setting things up and making decision in imagej discussion. If we can address the scifio merge/refactor the same way, that would be great. But we have to be careful if scifio gets out into the wild, then we will quickly tie our hands.
      • Curtis: From now we have still a lot of flexibility to change our minds (probably until the end of scifio). We will do changes on few levels , one are trivial, other requires more investigation.
      • Andrew: if these all packages are going to be maintained by ome, does it make sense have the entire hierarchy in ome.*?
      • Curtis: would love to see that happen. We had talked about moving bio-formats to ome-formats. Had though about ome-scifio, but there’s the historical issue of ome==open microscopy. Perhaps open metadata? Want to avoid associating this only with metadata.
      • Jason: the branding is ome and less “open microscopy”, is just not microscopy, but data, metadata, etc.
      • Curtis: lets call it ome-scifo package. Have always seen this as an OME product.
      • Chris: with respect to git and the branches. bioformats will be evolving during the 4.4 cycle in develop. You mean “merge to develop” right? Correct.
      • Curtis: 2 step process, we merge to develop, Melissa then merge to master.
      • Chris: means there are no merges to any other branches right?
      • Curtis:I see that sooner rather then later we merge scifio branch to develop.
      • Chris: This is more now moving from bioformats/component to components/scifio
      • Curtis: Scifio.jar is a new dependencie we need to define in xml structure.
      • Chris: Underline functionality should not change at all. Correct.
      • Curtis: Scifio.jar is components/scifio, to make it clear.
      • Jason: Mark would you use any of out mechanism help us to keep track on changes (git,trac, etc)?
      • Mark: Yes, I would be happy to make it visible for everyone.
      • Andrew: you were talking about scifio being ndim. Wanted to point out the module add on.
      • Mark: It will be defined in schema, give back the arbitrary order of dimensions.
      • Josh: How image lib will be supported?
      • Curtis: If we decide imglib interfaces useful, but that was not intention, more like a special package. Idea is open.
      • Josh: would be good to have it clear which interfaces are responsible for image stuff, etc. It could prevent adding new layers on top of other layers to hack something.
      • Josh: When I try to explain how dependency graph look like this is not exactly clear.
      • Curtis: will try to prepare a list of problems with various APIs (imglib/ij2/etc.) by the end of this week for discussion in Dresden.
      • Chris: The changes we are doing here affect everyone, we will organize status meeting soon, to be sure everyone is up to date.
  • Any other business (<5 mins)
    • Scott: training from EDI. Off call.
  • Done at 16:09
Document Actions