Image Cooperative https://image.coop/blog/ quarto-1.8.25 Tue, 21 Apr 2026 07:00:00 GMT Image Cooperative’s first order of business: helping push the OME-Zarr standard forward The Image Cooperative team https://image.coop/blog/posts/2026/04/21/announcing-biohub-contract/

Summary

(The 0th order of business was standing up the business.)

TLDR: Biohub is supporting the development of the OME-Zarr standard through a contract managed by Image Cooperative and supporting many other stakeholders from the OME-Zarr community. Our ambitious goal is to deliver at least an alpha version of OME-Zarr 1.0 in the first quarter of 2027.

Read on for the details!

Announcing our first partnership

We’re pleased to announce that Biohub is supporting the further development of OME-Zarr through a project coordinated by Image Cooperative. Rather than concentrating this work within a single organisation, the funding allows us to distribute effort across a group of initial partners who are already deeply involved in the OME-Zarr ecosystem, including Fideus Labs, scalable minds, German BioImaging, University of Dundee and Glencoe Software.

This is exactly the model Image Cooperative was created to support: shared ownership of both the work and its outcomes, with resources flowing to the people actively building and maintaining the ecosystem. We’re excited to be working together—and with the wider community—to move OME-Zarr forward.

What is OME-Zarr?

For those unfamiliar, Zarr is a file format for storing numeric array data, and corresponding metadata. OME-Zarr is an evolving metadata standard on top of Zarr for storing image data. Together, they solve many of the issues working with image data today, particularly microscopy image data:

  • Data often comes in multiple competing proprietary file formats1.
  • The most widespread open format, and predecessor to OME-Zarr, OME-TIFF, has complex metadata, resulting in incomplete support across software platforms.
  • Large TIFF files are difficult to share in cloud environments, often requiring a complete download to inspect and analyse the data.
  • Modern image data can span many gigabytes or even terabytes, making TIFF impractical.

The Zarr file format addresses most of these issues: it is an open file format, and the array data is “chunked”, which means that, to look at a small subset of data, you only need to download a correspondingly small subset of chunks, dramatically improving the experience of working with remote data. It also supports advanced (and customisable) compression algorithms, which helps with data size.

Missing, though, is a description of how to interpret these chunks as (bio-)imaging data. By default, a Zarr file contains just the array data and a little bit of extra information about how to decode and reshape that data into, say, an array of “height” 1080 by “width” 1920 by “depth” 30. There’s nothing there about these elements being pixels, whether one of the dimensions is temporal (as in a sequence of frames), how far those pixels extend in physical space, and certainly not about whether the camera was rotated relative to some scientifically important frame.

This is where OME-Zarr comes in. Zarr has room in its “extra information” file for custom metadata. You could put just about anything in there, but there is power in everyone agreeing on what to call things (like the distance between pixels: that is a “scale” “coordinateTransformation”, in OME-Zarr parlance). Then, scientific software developers can all look in the same place for that information and process the data correctly. OME-Zarr is the standard for how to organise image metadata within the Zarr metadata store.

Those who have followed the development of OME-Zarr will know that progress has sometimes felt slower than the format’s clear utility and growing adoption might suggest. That is not unexpected: standards work is inherently difficult, especially when it is done in the open and aims to incorporate broad community input, as OME-Zarr has. Long timelines are not unusual in this space—the Protein Data Bank (PDB) format, for example, took decades to mature.

At the same time, this process can be frustrating. Good proposals can take years to converge on, sometimes over relatively small points of disagreement. And in a largely volunteer-driven effort, it is not uncommon for valuable ideas to stall simply because there is no time to write them up, refine them, or turn them into working implementations. This is exactly the gap we are trying to help address: turning community energy into maintained momentum, and helping reduce the friction between ideas, agreement, and implementation.

How are we helping?

Our goal is to move the OME-Zarr format forward to version 1.0 by building community capacity. The Biohub contract funds our time to shepherd community discussion through the established specification process. Some of our work will be performing mundane, but important tasks that are difficult to ask of volunteers, such as coordinating reviews on proposals (“RFCs” in OME-Zarr parlance). We will also be working on implementations of the specification, with the aim of extending existing software over creating new software. But before doing so, our first step is to listen. In the coming weeks, we will be meeting with the community to get a better sense of the needs and pains — for contributors to the spec, developers of implementations, and users of the format. This information will help us build a roadmap towards a “version 1.0”. We will do this through attending conferences (e.g., the 2026 OME Community Meeting), sharing surveys, and meeting with folks who have participated in OME-Zarr development thus far. We look forward to chatting with you!

Now you might be wondering, “what is this mythical version 1.0?” With version 1.0, the OME-Zarr community aims to release a version of the specification and implementations that meet all currently-identified critical needs, as documented by current RFCs. While the logistics of long-term support are still being worked out, we want version 1.0 to be complete enough that the community would want to support it long term. To be clear, we don’t intend version 1.0 to be the spec-to-end-all-specs. We know that the format specification is a living document that has to evolve with the needs of the scientific community. However, we also know that lack of support for some of the key features covered by in-flight RFCs is a barrier to adoption for many teams, and we hope that version 1.0 can lower those barriers for a wide range of use cases.

Where do we go from here?

This is our first partnership in this form—hopefully one of many. We see it as a template for how cooperative, distributed development can support shared infrastructure projects like OME-Zarr. We’re excited to learn from this work, to improve it as we go, and to keep building it together with the community.

Want to learn more?

For readers who want to go deeper, the OME community maintains a central NGFF/OME-Zarr hub with specifications, example data, and community resources, including a calendar listing community meetings and office hours — all are welcome to join!

]]> https://image.coop/blog/posts/2026/04/21/announcing-biohub-contract/ Tue, 21 Apr 2026 07:00:00 GMT Why we started Image Cooperative The Image Cooperative team https://image.coop/blog/posts/2026/03/16/why-image-cooperative/

summary

TLDR: Open software and infrastructure are poorly supported within today’s academic environment. Meanwhile, market forces seem to drive almost every “open” company towards acquisition, enshittification, or both. As we learned more about worker cooperatives, and our individual careers fortuitously aligned, we decided to jump: we are starting a worker cooperative to build, maintain, teach, and support open source scientific imaging software.

Read on for more details, and our individual perspectives.

introduction

Each of us at Image Cooperative has been in an academic setting and seen cash-strapped universities shell out $100,000 or even $1M+ for licenses to proprietary software (e.g. Matlab), while letting talented developers go because they “can’t afford” their wages. Meanwhile, open alternatives like Python and NumPy get by on a dime and the unpaid work of thousands of volunteers.

There’s amazing science happening in academic and research institutions all over the world, and we are still driven to be part of it, and support it. But if not as employees at the institutions themselves, then how?

Over the past few years, some of us did some freelancing, which is lonely and precarious. We contemplated starting a conventional for-profit company, but we were apprehensive about the broken incentives in corporate structures: owners and workers are fundamentally at odds with each other. Unions are a powerful tool to balance those odds, but they often result in an adversarial relationship between workers and owners/CEOs.

Two years ago, we came across Valerie Young’s excellent talk, Inside Igalia: Scaling a Co-Op Beyond 100 Members. If you are still reading, you should probably add it to your watch list.

Although we had varying degrees of familiarity with worker cooperatives, we had not seriously considered one, and the talk provided a proof-of-existence for a long-lived coop in the open source tech consulting space. Valerie speculates about “federated Igalia” at the end of the talk, but it turns out they weren’t quite ready to act on that, or this post might be titled “why we started imagigalia.” 😅

Nonetheless, Valerie kindly volunteered her time and provided valuable advice on how we could get started. We then got in touch with the Cooperative Federation, an Australian peak body representing cooperatives in Australia, and itself a cooperative (a meta-cooperative, if you will!). We mention this because this is our first time doing something like this and their help was absolutely priceless. We do hope our story will be long enough to inspire others to create different cooperatives, and, if you are in Australia, please get in touch with them. Otherwise, the International Cooperative Alliance can help you find a local group near you.

We will write many more posts about how much we love cooperatives, but for now, let’s pivot back to what we aim to do with the cooperative.

We all came together over shared values of what management, analysis, infrastructure, and publication should look like for scientific image data. Individually, we’ve solved parts of these problems in small ways (working with individual labs on part of these elements) and big ways (collaborating on or leading projects such as scikit-image, OME-TIFF, OME-NGFF, and napari). Together, and with your help 😉, we hope to make it easy for all scientists, indeed all institutions, to use open and reproducible pipelines for image data, all the way from acquisition to publication and archiving.

our members’ perspectives

Coming from an academic background, we all feel a bit cringey about corporate communications that try to average everyone’s perspective and end up being a beige blur. So, we thought we’d include in this post some short individual, non-averaged thoughts from all five of our founding members.

Draga Doncila Pop

Over the past four years I’ve been lucky, privileged and honoured to be paid to work on Open Source Software (mainly, napari), while completing my PhD. Nearing the end of my PhD has been a time of reflection – on where I’ve come from, what I’ve been doing, and what I want to do next. On one hand, I love research, and everything it stands for. On the other, I’ve consistently found the academic system to be at odds with its purported goals of expanding humanity’s knowledge, and access to that knowledge.

I felt heavy pressure to publish work I didn’t believe was ready. I heard horror stories from fellow PhD students who were overworked and undervalued. I listened to other, more senior, members of the faculty lament on the state of academic publishing, the decline in the quality of teaching, and the constant battle for funding. My work on open source research software was consistently dismissed by my Advisory Panel — “it’s great that you’re doing this, but it’s not research.” Nevertheless, I contemplated an academic pathway, via a postdoc. Maybe I could struggle through the early years and build myself a niche where I could make meaningful contributions to knowledge and put those contributions in scientists’ hands via well-maintained, robust open software. But, deep down, it felt like taking the academic pathway would be tantamount to giving up.

In my other life, I’ve been serving on the napari Steering Council. I’ve seen first hand how difficult it is to get funding for Open Source Software – the funding opportunities are few, and projects that enable both academia and industry to succeed must fight for scraps. Time and time again when discussing funding, we questioned whether things would’ve been easier if we’d just decided to sell a product. But the life of napari, and other projects like it, is its community – we’re open, welcoming and always happy for others to join the fray. These are the qualities that make me love Open Source Software, and that made me love the collaborative work I did during my PhD. From a personal perspective though I had to ask – can I afford to commit to Open Source Software full time? Can I make a living from it, in the long term? Should I just “get a real job”? Another option that felt like giving up.

Image Coop doesn’t feel like giving up. It feels like an opportunity to keep doing the things I love, to keep enabling researchers and scientists to do the things they love, to work together to build something open, equitable and sustainable. I’m equal parts excited and terrified to start this journey. In my experience, that’s where the magic happens.

Eric Perlman

Throughout my career, I’ve worked on making image (and image-like) data open and accessible to everyone. While working at Janelia (where I met Juan) in Davi Bock’s lab, I worked on the imaging data pipeline that moved images from microscope, to storage, analysis, and researcher annotation with CATMAID, yielding the full adult fly brain (FAFB) dataset.

One critical, formative lesson for me is that value in making data public: FlyWire combined our published data with advances in image analysis, cutting edge web-based visualisation tools like Neuroglancer, and citizen science to produce the first full-brain Drosophila connectome. The response was immense, with media coverage including The New York Times, the BBC, The Gaurdian and even Saturday Night Live (seriously). For me, this concretely demonstrated the value of open data, open source software in science, and I’ve made it a part of my mission ever since.

Using my experience and connections from within this community, I was able to establish myself as a freelancer. This has given me the opportunity to work on many cool scientific problems with great people. It’s been a joy working across multiple groups all fundamentally driven by a love of science. (I’ve actually been encouraging Juan to try it for some time now!)

When Juan told me he was getting ready to actually take the leap, I was excited. Having grown up in Berkeley, I’m no stranger to workers’ cooperatives. In fact, my mom was a member of the now-legendary Cheese Board Collective. So having this organization be a cooperative is in some sense a return to my roots, which feels wonderful. And it’ll be good to combine the scientific freedom of freelancing with the collaborative spirit (and support) of a cooperative.

Kevin Yamauchi

Throughout my scientific career, I have been drawn to bioimaging. I love marveling at beautiful images of cells, tissues, and organisms and wondering how it all fits together. I have worked across many biology-adjacent fields ranging from biophysics to diagnostics, but the common thread that kept me excited was developing new methods and seeing them used to make observations and insights. From early on in my scientific career, I grappled with the latter: how do I share the methods I am developing outside of the lab I am working in?

When I discovered community-driven open source software, the light bulb turned on. Suddenly, I was able to collaborate with people from across the globe who were excited about the same things as me. No more wasting time reinventing the wheel. We pooled our different expertise to solve problems that none of us could have solved individually. Working on community-driven projects like napari and SpatialData really drove home for me how important it is that scientific software is owned by the community and not companies. Our continued scientific progress depends in part on our software evolving to meet the needs of cutting edge scientific questions and not the needs of shareholders.

As an academic, I felt a constant tension trying to balance the incentives that drive the academic system with the clear need for well-maintained open source scientific software. While I was fortunate to have mentors who supported my open source contributions, it was always clear it wasn’t the priority. In many conversations with my co-founders over the years, we wondered if there are ways we can organize the labor that supports open source scientific software that doesn’t feel like swimming upstream.

Co-founding the Image Cooperative feels like an exciting opportunity to try to establish a sustainable path for developers and maintainers of open source scientific software. I have no idea if this experiment will work, but I am feeling optimistic as I couldn’t ask for a kinder or more talented team of co-founders. I think it is clear that the way we write code is changing rapidly, so what better time to experiment with the systems that structure how we work?

Josh Moore

For the last 20 years I’ve been incredibly lucky to be supported to work full time on open source software. Almost all of that time has been spent on the OME project, which I think stands as a remarkable example of building production-quality software in the open, for the benefit of a global scientific community. Working alongside so many talented scientists, developers, and research software engineers has been without a doubt the great privilege of my career.

At the same time, my path through academia has always been a slightly unusual one. I never completed a PhD, and despite the impact of the work and the success of projects like OME, that has limited the formal roles available to me within academic institutions. More broadly, it has often felt like the academic system doesn’t quite know what to do with people whose primary contribution is building and maintaining research software.

Many years ago, while I was at the University of Dundee, representatives from funding bodies asked us whether we saw a clear career path for the work we were doing. At the time, we had to admit that we didn’t really know. In truth, even now, the long-term structures that support open scientific infrastructure still feel fragile.

The Image Cooperative is an opportunity to try something new. I’m not leaving my work with German BioImaging — which continues to be deeply meaningful to me and important to the community — but the cooperative offers a complementary path. For many senior research software engineers, especially those who care deeply about open infrastructure, it provides a model that could allow us to continue doing the work we believe in while building something sustainable.

Looking ahead, I would love to see the Image Cooperative grow, or even better, to see many more cooperatives emerge. My hope is that this becomes part of a broader ecosystem: communities of people building the tools they care about, supporting each other, and doing work they love for the right reasons.

Juan Nunez-Iglesias

I think a lot of my career can be described by the phrase, “there must be a better way!”, after which I would go down various rabbit holes, often to the detriment of my actual science questions, but, I hope, to the benefit of many others’. During my PhD, I gave a talk to my labmates about Subversion (the thing that was there before git, for the young’ins in the audience), and how we should stop having our code in folders named after the date, and for a couple of years the lab subversion server was my desktop. Later, I would sometimes spend months upstreaming code to open source libraries like scikit-image, to the chagrin of my PIs.

That kind of work really wasn’t valued in academic circles, resulting in precarious employment for most of my career. The only exception was a three year contract from Ian Harper at Monash Micro Imaging, for which I am forever grateful, and a fellowship from CZI, for which I am also forever grateful. The latter was renewed twice (more gratitude!), but as each renewal approached, I was told by Monash leadership that I wouldn’t have a job without it. Needless to say, that felt terrible, and I’d been contemplating freelancing since that first conversation, in 2021 — and with encouragement from and thanks to our co-founder Eric Perlman, who had been doing it for some years now.

But I had already done a bit of freelancing on the side in the past, and it was lonely, and felt even more precarious. I really wasn’t looking forward to it.

That’s when I came across Valerie’s talk (mentioned above). I watched it twice, breathlessly shared it on #randoms in the napari Zulip (open login required), and it’s been on my mind ever since, rent-free as they say. I shared it and discussed it as often as I could, including with this lot. 😂 By last August, I knew my fellowship was coming to an end and this was definitely do or die for me.

Many conversations later, here we are. Like Draga, I’m equal parts exhilarated and terrified. But, mostly I am, yet again, insanely grateful to have my co-founders with me and to be starting something we deeply believe in. “There must be a better way…” Is this it? I sure as hell hope so.

closing thoughts

We all believe in the ideals of the Academy, in the pursuit of knowledge for knowledge’s sake, and in the construction of things that improve the world and outlast us. There is an alternate timeline in which academics have stable jobs, are valued for their craft rather than their output, and none of us feels a need to go out and found this cooperative.

That is not our timeline. So we’re trying something else. We’re actually tremendously excited because, together, we have a really diverse set of skills to solve the problems we want to solve: data visualisation, data analysis, (bio)physical modelling, large data handling, cloud data, image data standards, open source development, and more.

So we have an excellent opportunity to push image analysis in science forward. If you’re struggling with image data, at any stage in the pipeline, please share this widely with your colleagues, and think about whether some of the proprietary license money you’re currently spending could be spent instead on open solutions that would be yours forever, endlessly adaptable, and benefit the entire world. And please get in touch by emailing info@image.coop.

If you think you want to work at Image Cooperative, please look at our joining page. We are at the very earliest stages of our history, and we need new contracts to grow, but our ambition is that, 20 years from now, we will also have a YouTube PeerTube talk: Inside Image Cooperative: how to scale a scientific imaging cooperative to over 100 members.

]]> https://image.coop/blog/posts/2026/03/16/why-image-cooperative/ Mon, 16 Mar 2026 07:00:00 GMT