Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data

Med-ImageTools: An open-source Python package for... | F1000Research "use strict";function _typeof(t){return(_typeof="function"==typeof Symbol&&"symbol"==typeof Symbol.iterator?function(t){return typeof t}:function(t){return t&&"function"==typeof Symbol&&t.constructor===Symbol&&t!==Symbol.prototype?"symbol":typeof t})(t)}!function(){var t=function(){var t,e,o=[],n=window,r=n;for(;r;){try{if(r.frames.__tcfapiLocator){t=r;break}}catch(t){}if(r===n.top)break;r=r.parent}t||(!function t(){var e=n.document,o=!!n.frames.__tcfapiLocator;if(!o)if(e.body){var r=e.createElement("iframe");r.style.cssText="display:none",r.name="__tcfapiLocator",e.body.appendChild(r)}else setTimeout(t,5);return!o}(),n.__tcfapi=function(){for(var t=arguments.length,n=new Array(t),r=0;r 3&&2===parseInt(n[1],10)&&"boolean"==typeof n[3]&&(e=n[3],"function"==typeof n[2]&&n[2]("set",!0)):"ping"===n[0]?"function"==typeof n[2]&&n[2]({gdprApplies:e,cmpLoaded:!1,cmpStatus:"stub"}):o.push(n)},n.addEventListener("message",(function(t){var e="string"==typeof t.data,o={};if(e)try{o=JSON.parse(t.data)}catch(t){}else o=t.data;var n="object"===_typeof(o)&&null!==o?o.__tcfapiCall:null;n&&window.__tcfapi(n.command,n.version,(function(o,r){var a={__tcfapiReturn:{returnValue:o,success:r,callId:n.callId}};t&&t.source&&t.source.postMessage&&t.source.postMessage(e?JSON.stringify(a):a,"*")}),n.parameter)}),!1))};"undefined"!=typeof module?module.exports=t:t()}(); dataLayer = dataLayer || []; // Standard GTM initialization - Google Consent Mode handles consent automatically (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start': new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0], j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src= 'https://www.googletagmanager.com/gtm.js?id='+i+dl+ '>m_auth=hzk0Vc3qFsQYhCrIoHz68A>m_preview=env-1>m_cookies_win=x';f.parentNode.insertBefore(j,f); })(window,document,'script','dataLayer','GTM-MWFK8L5J'); ;window.NREUM||(NREUM={});NREUM.init={distributed_tracing:{enabled:true},privacy:{cookies_enabled:true},ajax:{deny_list:["bam.nr-data.net"]}}; ;NREUM.loader_config={accountID:"438030",trustKey:"438030",agentID:"772317073",licenseKey:"97f8f67f26",applicationID:"772317073"} ;NREUM.info={beacon:"bam.nr-data.net",errorBeacon:"bam.nr-data.net",licenseKey:"97f8f67f26",applicationID:"772317073",sa:1} ;/*! For license information please see nr-loader-spa-1.236.0.min.js.LICENSE.txt */ (()=>{"use strict";var e,t,r={5763:(e,t,r)=>{r.d(t,{P_:()=>l,Mt:()=>g,C5:()=>s,DL:()=>v,OP:()=>T,lF:()=>D,Yu:()=>y,Dg:()=>h,CX:()=>c,GE:()=>b,sU:()=>_});var n=r(8632),i=r(9567);const o={beacon:n.ce.beacon,errorBeacon:n.ce.errorBeacon,licenseKey:void 0,applicationID:void 0,sa:void 0,queueTime:void 0,applicationTime:void 0,ttGuid:void 0,user:void 0,account:void 0,product:void 0,extra:void 0,jsAttributes:{},userAttributes:void 0,atts:void 0,transactionName:void 0,tNamePlain:void 0},a={};function s(e){if(!e)throw new Error("All info objects require an agent identifier!");if(!a[e])throw new Error("Info for ".concat(e," was never set"));return a[e]}function c(e,t){if(!e)throw new Error("All info objects require an agent identifier!");a[e]=(0,i.D)(t,o),(0,n.Qy)(e,a[e],"info")}var u=r(7056);const d=()=>{const e={blockSelector:"[data-nr-block]",maskInputOptions:{password:!0}};return{allow_bfcache:!0,privacy:{cookies_enabled:!0},ajax:{deny_list:void 0,enabled:!0,harvestTimeSeconds:10},distributed_tracing:{enabled:void 0,exclude_newrelic_header:void 0,cors_use_newrelic_header:void 0,cors_use_tracecontext_headers:void 0,allowed_origins:void 0},session:{domain:void 0,expiresMs:u.oD,inactiveMs:u.Hb},ssl:void 0,obfuscate:void 0,jserrors:{enabled:!0,harvestTimeSeconds:10},metrics:{enabled:!0},page_action:{enabled:!0,harvestTimeSeconds:30},page_view_event:{enabled:!0},page_view_timing:{enabled:!0,harvestTimeSeconds:30,long_task:!1},session_trace:{enabled:!0,harvestTimeSeconds:10},harvest:{tooManyRequestsDelay:60},session_replay:{enabled:!1,harvestTimeSeconds:60,sampleRate:.1,errorSampleRate:.1,maskTextSelector:"*",maskAllInputs:!0,get blockClass(){return"nr-block"},get ignoreClass(){return"nr-ignore"},get maskTextClass(){return"nr-mask"},get blockSelector(){return e.blockSelector},set blockSelector(t){e.blockSelector+=",".concat(t)},get maskInputOptions(){return e.maskInputOptions},set maskInputOptions(t){e.maskInputOptions={...t,password:!0}}},spa:{enabled:!0,harvestTimeSeconds:10}}},f={};function l(e){if(!e)throw new Error("All configuration objects require an agent identifier!");if(!f[e])throw new Error("Configuration for ".concat(e," was never set"));return f[e]}function h(e,t){if(!e)throw new Error("All configuration objects require an agent identifier!");f[e]=(0,i.D)(t,d()),(0,n.Qy)(e,f[e],"config")}function g(e,t){if(!e)throw new Error("All configuration objects require an agent identifier!");var r=l(e);if(r){for(var n=t.split("."),i=0;i {r.d(t,{D:()=>i});var n=r(50);function i(e,t){try{if(!e||"object"!=typeof e)return(0,n.Z)("Setting a Configurable requires an object as input");if(!t||"object"!=typeof t)return(0,n.Z)("Setting a Configurable requires a model to set its initial properties");const r=Object.create(Object.getPrototypeOf(t),Object.getOwnPropertyDescriptors(t)),o=0===Object.keys(r).length?e:r;for(let a in o)if(void 0!==e[a])try{"object"==typeof e[a]&&"object"==typeof t[a]?r[a]=i(e[a],t[a]):r[a]=e[a]}catch(e){(0,n.Z)("An error occurred while setting a property of a Configurable",e)}return r}catch(e){(0,n.Z)("An error occured while setting a Configurable",e)}}},6818:(e,t,r)=>{r.d(t,{Re:()=>i,gF:()=>o,q4:()=>n});const n="1.236.0",i="PROD",o="CDN"},385:(e,t,r)=>{r.d(t,{FN:()=>a,IF:()=>u,Nk:()=>f,Tt:()=>s,_A:()=>o,il:()=>n,pL:()=>c,v6:()=>i,w1:()=>d});const n="undefined"!=typeof window&&!!window.document,i="undefined"!=typeof WorkerGlobalScope&&("undefined"!=typeof self&&self instanceof WorkerGlobalScope&&self.navigator instanceof WorkerNavigator||"undefined"!=typeof globalThis&&globalThis instanceof WorkerGlobalScope&&globalThis.navigator instanceof WorkerNavigator),o=n?window:"undefined"!=typeof WorkerGlobalScope&&("undefined"!=typeof self&&self instanceof WorkerGlobalScope&&self||"undefined"!=typeof globalThis&&globalThis instanceof WorkerGlobalScope&&globalThis),a=""+o?.location,s=/iPad|iPhone|iPod/.test(navigator.userAgent),c=s&&"undefined"==typeof SharedWorker,u=(()=>{const e=navigator.userAgent.match(/Firefox[/\s](\d+\.\d+)/);return Array.isArray(e)&&e.length>=2?+e[1]:0})(),d=Boolean(n&&window.document.documentMode),f=!!navigator.sendBeacon},1117:(e,t,r)=>{r.d(t,{w:()=>o});var n=r(50);const i={agentIdentifier:"",ee:void 0};class o{constructor(e){try{if("object"!=typeof e)return(0,n.Z)("shared context requires an object as input");this.sharedContext={},Object.assign(this.sharedContext,i),Object.entries(e).forEach((e=>{let[t,r]=e;Object.keys(i).includes(t)&&(this.sharedContext[t]=r)}))}catch(e){(0,n.Z)("An error occured while setting SharedContext",e)}}}},8e3:(e,t,r)=>{r.d(t,{L:()=>d,R:()=>c});var n=r(2177),i=r(1284),o=r(4322),a=r(3325);const s={};function c(e,t){const r={staged:!1,priority:a.p[t]||0};u(e),s[e].get(t)||s[e].set(t,r)}function u(e){e&&(s[e]||(s[e]=new Map))}function d(){let e=arguments.length>0&&void 0!==arguments[0]?arguments[0]:"",t=arguments.length>1&&void 0!==arguments[1]?arguments[1]:"feature";if(u(e),!e||!s[e].get(t))return a(t);s[e].get(t).staged=!0;const r=[...s[e]];function a(t){const r=e?n.ee.get(e):n.ee,a=o.X.handlers;if(r.backlog&&a){var s=r.backlog[t],c=a[t];if(c){for(var u=0;s&&u {let[t,r]=e;return r.staged}))&&(r.sort(((e,t)=>e[1].priority-t[1].priority)),r.forEach((e=>{let[t]=e;a(t)})))}function f(e,t){var r=e[1];(0,i.D)(t[r],(function(t,r){var n=e[0];if(r[0]===n){var i=r[1],o=e[3],a=e[2];i.apply(o,a)}}))}},2177:(e,t,r)=>{r.d(t,{c:()=>f,ee:()=>u});var n=r(8632),i=r(2210),o=r(1284),a=r(5763),s="nr@context";let c=(0,n.fP)();var u;function d(){}function f(e){return(0,i.X)(e,s,l)}function l(){return new d}function h(){u.aborted=!0,u.backlog={}}c.ee?u=c.ee:(u=function e(t,r){var n={},c={},f={},g=!1;try{g=16===r.length&&(0,a.OP)(r).isolatedBacklog}catch(e){}var p={on:b,addEventListener:b,removeEventListener:y,emit:v,get:x,listeners:w,context:m,buffer:A,abort:h,aborted:!1,isBuffering:E,debugId:r,backlog:g?{}:t&&"object"==typeof t.backlog?t.backlog:{}};return p;function m(e){return e&&e instanceof d?e:e?(0,i.X)(e,s,l):l()}function v(e,r,n,i,o){if(!1!==o&&(o=!0),!u.aborted||i){t&&o&&t.emit(e,r,n);for(var a=m(n),s=w(e),d=s.length,f=0;fn,p:()=>i});var n=r(2177).ee.get("handle");function i(e,t,r,i,o){o?(o.buffer([e],i),o.emit(e,t,r)):(n.buffer([e],i),n.emit(e,t,r))}},4322:(e,t,r)=>{r.d(t,{X:()=>o});var n=r(5546);o.on=a;var i=o.handlers={};function o(e,t,r,o){a(o||n.E,i,e,t,r)}function a(e,t,r,i,o){o||(o="feature"),e||(e=n.E);var a=t[o]=t[o]||{};(a[r]=a[r]||[]).push([e,i])}},3239:(e,t,r)=>{r.d(t,{bP:()=>s,iz:()=>c,m$:()=>a});var n=r(385);let i=!1,o=!1;try{const e={get passive(){return i=!0,!1},get signal(){return o=!0,!1}};n._A.addEventListener("test",null,e),n._A.removeEventListener("test",null,e)}catch(e){}function a(e,t){return i||o?{capture:!!e,passive:i,signal:t}:!!e}function s(e,t){let r=arguments.length>2&&void 0!==arguments[2]&&arguments[2],n=arguments.length>3?arguments[3]:void 0;window.addEventListener(e,t,a(r,n))}function c(e,t){let r=arguments.length>2&&void 0!==arguments[2]&&arguments[2],n=arguments.length>3?arguments[3]:void 0;document.addEventListener(e,t,a(r,n))}},4402:(e,t,r)=>{r.d(t,{Ht:()=>u,M:()=>c,Rl:()=>a,ky:()=>s});var n=r(385);const i="xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx";function o(e,t){return e?15&e[t]:16*Math.random()|0}function a(){const e=n._A?.crypto||n._A?.msCrypto;let t,r=0;return e&&e.getRandomValues&&(t=e.getRandomValues(new Uint8Array(31))),i.split("").map((e=>"x"===e?o(t,++r).toString(16):"y"===e?(3&o()|8).toString(16):e)).join("")}function s(e){const t=n._A?.crypto||n._A?.msCrypto;let r,i=0;t&&t.getRandomValues&&(r=t.getRandomValues(new Uint8Array(31)));const a=[];for(var s=0;s {r.d(t,{Bq:()=>n,Hb:()=>o,oD:()=>i});const n="NRBA",i=144e5,o=18e5},7894:(e,t,r)=>{function n(){return Math.round(performance.now())}r.d(t,{z:()=>n})},7243:(e,t,r)=>{r.d(t,{e:()=>o});var n=r(385),i={};function o(e){if(e in i)return i[e];if(0===(e||"").indexOf("data:"))return{protocol:"data"};let t;var r=n._A?.location,o={};if(n.il)t=document.createElement("a"),t.href=e;else try{t=new URL(e,r.href)}catch(e){return o}o.port=t.port;var a=t.href.split("://");!o.port&&a[1]&&(o.port=a[1].split("/")[0].split("@").pop().split(":")[1]),o.port&&"0"!==o.port||(o.port="https"===a[0]?"443":"80"),o.hostname=t.hostname||r.hostname,o.pathname=t.pathname,o.protocol=a[0],"/"!==o.pathname.charAt(0)&&(o.pathname="/"+o.pathname);var s=!t.protocol||":"===t.protocol||t.protocol===r.protocol,c=t.hostname===r.hostname&&t.port===r.port;return o.sameOrigin=s&&(!t.hostname||c),"/"===o.pathname&&(i[e]=o),o}},50:(e,t,r)=>{function n(e,t){"function"==typeof console.warn&&(console.warn("New Relic: ".concat(e)),t&&console.warn(t))}r.d(t,{Z:()=>n})},2587:(e,t,r)=>{r.d(t,{N:()=>c,T:()=>u});var n=r(2177),i=r(5546),o=r(8e3),a=r(3325);const s={stn:[a.D.sessionTrace],err:[a.D.jserrors,a.D.metrics],ins:[a.D.pageAction],spa:[a.D.spa],sr:[a.D.sessionReplay,a.D.sessionTrace]};function c(e,t){const r=n.ee.get(t);e&&"object"==typeof e&&(Object.entries(e).forEach((e=>{let[t,n]=e;void 0===u[t]&&(s[t]?s[t].forEach((e=>{n?(0,i.p)("feat-"+t,[],void 0,e,r):(0,i.p)("block-"+t,[],void 0,e,r),(0,i.p)("rumresp-"+t,[Boolean(n)],void 0,e,r)})):n&&(0,i.p)("feat-"+t,[],void 0,void 0,r),u[t]=Boolean(n))})),Object.keys(s).forEach((e=>{void 0===u[e]&&(s[e]?.forEach((t=>(0,i.p)("rumresp-"+e,[!1],void 0,t,r))),u[e]=!1)})),(0,o.L)(t,a.D.pageViewEvent))}const u={}},2210:(e,t,r)=>{r.d(t,{X:()=>i});var n=Object.prototype.hasOwnProperty;function i(e,t,r){if(n.call(e,t))return e[t];var i=r();if(Object.defineProperty&&Object.keys)try{return Object.defineProperty(e,t,{value:i,writable:!0,enumerable:!1}),i}catch(e){}return e[t]=i,i}},1284:(e,t,r)=>{r.d(t,{D:()=>n});const n=(e,t)=>Object.entries(e||{}).map((e=>{let[r,n]=e;return t(r,n)}))},4351:(e,t,r)=>{r.d(t,{P:()=>o});var n=r(2177);const i=()=>{const e=new WeakSet;return(t,r)=>{if("object"==typeof r&&null!==r){if(e.has(r))return;e.add(r)}return r}};function o(e){try{return JSON.stringify(e,i())}catch(e){try{n.ee.emit("internal-error",[e])}catch(e){}}}},3960:(e,t,r)=>{r.d(t,{K:()=>a,b:()=>o});var n=r(3239);function i(){return"undefined"==typeof document||"complete"===document.readyState}function o(e,t){if(i())return e();(0,n.bP)("load",e,t)}function a(e){if(i())return e();(0,n.iz)("DOMContentLoaded",e)}},8632:(e,t,r)=>{r.d(t,{EZ:()=>u,Qy:()=>c,ce:()=>o,fP:()=>a,gG:()=>d,mF:()=>s});var n=r(7894),i=r(385);const o={beacon:"bam.nr-data.net",errorBeacon:"bam.nr-data.net"};function a(){return i._A.NREUM||(i._A.NREUM={}),void 0===i._A.newrelic&&(i._A.newrelic=i._A.NREUM),i._A.NREUM}function s(){let e=a();return e.o||(e.o={ST:i._A.setTimeout,SI:i._A.setImmediate,CT:i._A.clearTimeout,XHR:i._A.XMLHttpRequest,REQ:i._A.Request,EV:i._A.Event,PR:i._A.Promise,MO:i._A.MutationObserver,FETCH:i._A.fetch}),e}function c(e,t,r){let i=a();const o=i.initializedAgents||{},s=o[e]||{};return Object.keys(s).length||(s.initializedAt={ms:(0,n.z)(),date:new Date}),i.initializedAgents={...o,[e]:{...s,[r]:t}},i}function u(e,t){a()[e]=t}function d(){return function(){let e=a();const t=e.info||{};e.info={beacon:o.beacon,errorBeacon:o.errorBeacon,...t}}(),function(){let e=a();const t=e.init||{};e.init={...t}}(),s(),function(){let e=a();const t=e.loader_config||{};e.loader_config={...t}}(),a()}},7956:(e,t,r)=>{r.d(t,{N:()=>i});var n=r(3239);function i(e){let t=arguments.length>1&&void 0!==arguments[1]&&arguments[1],r=arguments.length>2?arguments[2]:void 0,i=arguments.length>3?arguments[3]:void 0;return void(0,n.iz)("visibilitychange",(function(){if(t)return void("hidden"==document.visibilityState&&e());e(document.visibilityState)}),r,i)}},1214:(e,t,r)=>{r.d(t,{em:()=>v,u5:()=>N,QU:()=>S,_L:()=>I,Gm:()=>L,Lg:()=>M,gy:()=>U,BV:()=>Q,Kf:()=>ee});var n=r(2177);const i="nr@original";var o=Object.prototype.hasOwnProperty,a=!1;function s(e,t){return e||(e=n.ee),r.inPlace=function(e,t,n,i,o){n||(n="");var a,s,c,u="-"===n.charAt(0);for(c=0;c 2?n-2:0),o=2;o {r(A[T],e,w),r(E[T],e,w)})),r(l._A,"fetch",y),t.on(y+"end",(function(e,r){var n=this;if(r){var i=r.headers.get("content-length");null!==i&&(n.rxSize=i),t.emit(y+"done",[null,r],n)}else t.emit(y+"done",[e],n)})),t}const O={},j=["pushState","replaceState"];function S(e){const t=function(e){return(e||n.ee).get("history")}(e);return!l.il||O[t.debugId]++||(O[t.debugId]=1,s(t).inPlace(window.history,j,"-")),t}var P=r(3239);const C={},R=["appendChild","insertBefore","replaceChild"];function I(e){const t=function(e){return(e||n.ee).get("jsonp")}(e);if(!l.il||C[t.debugId])return t;C[t.debugId]=!0;var r=s(t),i=/[?&](?:callback|cb)=([^&#]+)/,o=/(.*)\.([^.]+)/,a=/^(\w+)(\.|$)(.*)$/;function c(e,t){var r=e.match(a),n=r[1],i=r[3];return i?c(i,t[n]):t[n]}return r.inPlace(Node.prototype,R,"dom-"),t.on("dom-start",(function(e){!function(e){if(!e||"string"!=typeof e.nodeName||"script"!==e.nodeName.toLowerCase())return;if("function"!=typeof e.addEventListener)return;var n=(a=e.src,s=a.match(i),s?s[1]:null);var a,s;if(!n)return;var u=function(e){var t=e.match(o);if(t&&t.length>=3)return{key:t[2],parent:c(t[1],window)};return{key:e,parent:window}}(n);if("function"!=typeof u.parent[u.key])return;var d={};function f(){t.emit("jsonp-end",[],d),e.removeEventListener("load",f,(0,P.m$)(!1)),e.removeEventListener("error",l,(0,P.m$)(!1))}function l(){t.emit("jsonp-error",[],d),t.emit("jsonp-end",[],d),e.removeEventListener("load",f,(0,P.m$)(!1)),e.removeEventListener("error",l,(0,P.m$)(!1))}r.inPlace(u.parent,[u.key],"cb-",d),e.addEventListener("load",f,(0,P.m$)(!1)),e.addEventListener("error",l,(0,P.m$)(!1)),t.emit("new-jsonp",[e.src],d)}(e[0])})),t}var k=r(5763);const H={};function L(e){const t=function(e){return(e||n.ee).get("mutation")}(e);if(!l.il||H[t.debugId])return t;H[t.debugId]=!0;var r=s(t),i=k.Yu.MO;return i&&(window.MutationObserver=function(e){return this instanceof i?new i(r(e,"fn-")):i.apply(this,arguments)},MutationObserver.prototype=i.prototype),t}const z={};function M(e){const t=function(e){return(e||n.ee).get("promise")}(e);if(z[t.debugId])return t;z[t.debugId]=!0;var r=n.c,o=s(t),a=k.Yu.PR;return a&&function(){function e(r){var n=t.context(),i=o(r,"executor-",n,null,!1);const s=Reflect.construct(a,[i],e);return t.context(s).getCtx=function(){return n},s}l._A.Promise=e,Object.defineProperty(e,"name",{value:"Promise"}),e.toString=function(){return a.toString()},Object.setPrototypeOf(e,a),["all","race"].forEach((function(r){const n=a[r];e[r]=function(e){let i=!1;[...e||[]].forEach((e=>{this.resolve(e).then(a("all"===r),a(!1))}));const o=n.apply(this,arguments);return o;function a(e){return function(){t.emit("propagate",[null,!i],o,!1,!1),i=i||!e}}}})),["resolve","reject"].forEach((function(r){const n=a[r];e[r]=function(e){const r=n.apply(this,arguments);return e!==r&&t.emit("propagate",[e,!0],r,!1,!1),r}})),e.prototype=a.prototype;const n=a.prototype.then;a.prototype.then=function(){var e=this,i=r(e);i.promise=e;for(var a=arguments.length,s=new Array(a),c=0;c e())),t};function m(e,t){i.inPlace(t,["onreadystatechange"],"fn-",E)}function b(){var e=this,t=r.context(e);e.readyState>3&&!t.resolved&&(t.resolved=!0,r.emit("xhr-resolved",[],e)),i.inPlace(e,f,"fn-",E)}if(function(e,t){for(var r in e)t[r]=e[r]}(o,p),p.prototype=o.prototype,i.inPlace(p.prototype,J,"-xhr-",E),r.on("send-xhr-start",(function(e,t){m(e,t),function(e){h.push(e),a&&(y?y.then(A):u?u(A):(w=-w,x.data=w))}(t)})),r.on("open-xhr-start",m),a){var y=c&&c.resolve();if(!u&&!c){var w=1,x=document.createTextNode(w);new a(A).observe(x,{characterData:!0})}}else t.on("fn-end",(function(e){e[0]&&e[0].type===d||A()}));function A(){for(var e=0;e {r.d(t,{t:()=>n});const n=r(3325).D.ajax},6660:(e,t,r)=>{r.d(t,{A:()=>i,t:()=>n});const n=r(3325).D.jserrors,i="nr@seenError"},3081:(e,t,r)=>{r.d(t,{gF:()=>o,mY:()=>i,t9:()=>n,vz:()=>s,xS:()=>a});const n=r(3325).D.metrics,i="sm",o="cm",a="storeSupportabilityMetrics",s="storeEventMetrics"},4649:(e,t,r)=>{r.d(t,{t:()=>n});const n=r(3325).D.pageAction},7633:(e,t,r)=>{r.d(t,{Dz:()=>i,OJ:()=>a,qw:()=>o,t9:()=>n});const n=r(3325).D.pageViewEvent,i="firstbyte",o="domcontent",a="windowload"},9251:(e,t,r)=>{r.d(t,{t:()=>n});const n=r(3325).D.pageViewTiming},3614:(e,t,r)=>{r.d(t,{BST_RESOURCE:()=>i,END:()=>s,FEATURE_NAME:()=>n,FN_END:()=>u,FN_START:()=>c,PUSH_STATE:()=>d,RESOURCE:()=>o,START:()=>a});const n=r(3325).D.sessionTrace,i="bstResource",o="resource",a="-start",s="-end",c="fn"+a,u="fn"+s,d="pushState"},7836:(e,t,r)=>{r.d(t,{BODY:()=>A,CB_END:()=>E,CB_START:()=>u,END:()=>x,FEATURE_NAME:()=>i,FETCH:()=>_,FETCH_BODY:()=>v,FETCH_DONE:()=>m,FETCH_START:()=>p,FN_END:()=>c,FN_START:()=>s,INTERACTION:()=>l,INTERACTION_API:()=>d,INTERACTION_EVENTS:()=>o,JSONP_END:()=>b,JSONP_NODE:()=>g,JS_TIME:()=>T,MAX_TIMER_BUDGET:()=>a,REMAINING:()=>f,SPA_NODE:()=>h,START:()=>w,originalSetTimeout:()=>y});var n=r(5763);const i=r(3325).D.spa,o=["click","submit","keypress","keydown","keyup","change"],a=999,s="fn-start",c="fn-end",u="cb-start",d="api-ixn-",f="remaining",l="interaction",h="spaNode",g="jsonpNode",p="fetch-start",m="fetch-done",v="fetch-body-",b="jsonp-end",y=n.Yu.ST,w="-start",x="-end",A="-body",E="cb"+x,T="jsTime",_="fetch"},5938:(e,t,r)=>{r.d(t,{W:()=>o});var n=r(5763),i=r(2177);class o{constructor(e,t,r){this.agentIdentifier=e,this.aggregator=t,this.ee=i.ee.get(e,(0,n.OP)(this.agentIdentifier).isolatedBacklog),this.featureName=r,this.blocked=!1}}},9144:(e,t,r)=>{r.d(t,{j:()=>m});var n=r(3325),i=r(5763),o=r(5546),a=r(2177),s=r(7894),c=r(8e3),u=r(3960),d=r(385),f=r(50),l=r(3081),h=r(8632);function g(){const e=(0,h.gG)();["setErrorHandler","finished","addToTrace","inlineHit","addRelease","addPageAction","setCurrentRouteName","setPageViewName","setCustomAttribute","interaction","noticeError","setUserId"].forEach((t=>{e[t]=function(){for(var r=arguments.length,n=new Array(r),i=0;i 1?r-1:0),i=1;i {e.exposed&&e.api[t]&&o.push(e.api[t](...n))})),o.length>1?o:o[0]}(t,...n)}}))}var p=r(2587);function m(e){let t=arguments.length>1&&void 0!==arguments[1]?arguments[1]:{},m=arguments.length>2?arguments[2]:void 0,v=arguments.length>3?arguments[3]:void 0,{init:b,info:y,loader_config:w,runtime:x={loaderType:m},exposed:A=!0}=t;const E=(0,h.gG)();y||(b=E.init,y=E.info,w=E.loader_config),(0,i.Dg)(e,b||{}),(0,i.GE)(e,w||{}),(0,i.sU)(e,x),y.jsAttributes??={},d.v6&&(y.jsAttributes.isWorker=!0),(0,i.CX)(e,y),g();const T=function(e,t){t||(0,c.R)(e,"api");const h={};var g=a.ee.get(e),p=g.get("tracer"),m="api-",v=m+"ixn-";function b(t,r,n,o){const a=(0,i.C5)(e);return null===r?delete a.jsAttributes[t]:(0,i.CX)(e,{...a,jsAttributes:{...a.jsAttributes,[t]:r}}),x(m,n,!0,o||null===r?"session":void 0)(t,r)}function y(){}["setErrorHandler","finished","addToTrace","inlineHit","addRelease"].forEach((e=>h[e]=x(m,e,!0,"api"))),h.addPageAction=x(m,"addPageAction",!0,n.D.pageAction),h.setCurrentRouteName=x(m,"routeName",!0,n.D.spa),h.setPageViewName=function(t,r){if("string"==typeof t)return"/"!==t.charAt(0)&&(t="/"+t),(0,i.OP)(e).customTransaction=(r||"http://custom.transaction")+t,x(m,"setPageViewName",!0)()},h.setCustomAttribute=function(e,t){let r=arguments.length>2&&void 0!==arguments[2]&&arguments[2];if("string"==typeof e){if(["string","number"].includes(typeof t)||null===t)return b(e,t,"setCustomAttribute",r);(0,f.Z)("Failed to execute setCustomAttribute.\nNon-null value must be a string or number type, but a type of was provided."))}else(0,f.Z)("Failed to execute setCustomAttribute.\nName must be a string type, but a type of was provided."))},h.setUserId=function(e){if("string"==typeof e||null===e)return b("enduser.id",e,"setUserId",!0);(0,f.Z)("Failed to execute setUserId.\nNon-null value must be a string type, but a type of was provided."))},h.interaction=function(){return(new y).get()};var w=y.prototype={createTracer:function(e,t){var r={},i=this,a="function"==typeof t;return(0,o.p)(v+"tracer",[(0,s.z)(),e,r],i,n.D.spa,g),function(){if(p.emit((a?"":"no-")+"fn-start",[(0,s.z)(),i,a],r),a)try{return t.apply(this,arguments)}catch(e){throw p.emit("fn-err",[arguments,this,"string"==typeof e?new Error(e):e],r),e}finally{p.emit("fn-end",[(0,s.z)()],r)}}}};function x(e,t,r,i){return function(){return(0,o.p)(l.xS,["API/"+t+"/called"],void 0,n.D.metrics,g),i&&(0,o.p)(e+t,[(0,s.z)(),...arguments],r?null:this,i,g),r?void 0:this}}function A(){r.e(439).then(r.bind(r,7438)).then((t=>{let{setAPI:r}=t;r(e),(0,c.L)(e,"api")})).catch((()=>(0,f.Z)("Downloading runtime APIs failed...")))}return["actionText","setName","setAttribute","save","ignore","onEnd","getContext","end","get"].forEach((e=>{w[e]=x(v,e,void 0,n.D.spa)})),h.noticeError=function(e,t){"string"==typeof e&&(e=new Error(e)),(0,o.p)(l.xS,["API/noticeError/called"],void 0,n.D.metrics,g),(0,o.p)("err",[e,(0,s.z)(),!1,t],void 0,n.D.jserrors,g)},d.il?(0,u.b)((()=>A()),!0):A(),h}(e,v);return(0,h.Qy)(e,T,"api"),(0,h.Qy)(e,A,"exposed"),(0,h.EZ)("activatedFeatures",p.T),T}},3325:(e,t,r)=>{r.d(t,{D:()=>n,p:()=>i});const n={ajax:"ajax",jserrors:"jserrors",metrics:"metrics",pageAction:"page_action",pageViewEvent:"page_view_event",pageViewTiming:"page_view_timing",sessionReplay:"session_replay",sessionTrace:"session_trace",spa:"spa"},i={[n.pageViewEvent]:1,[n.pageViewTiming]:2,[n.metrics]:3,[n.jserrors]:4,[n.ajax]:5,[n.sessionTrace]:6,[n.pageAction]:7,[n.spa]:8,[n.sessionReplay]:9}}},n={};function i(e){var t=n[e];if(void 0!==t)return t.exports;var o=n[e]={exports:{}};return r[e](o,o.exports,i),o.exports}i.m=r,i.d=(e,t)=>{for(var r in t)i.o(t,r)&&!i.o(e,r)&&Object.defineProperty(e,r,{enumerable:!0,get:t[r]})},i.f={},i.e=e=>Promise.all(Object.keys(i.f).reduce(((t,r)=>(i.f[r](e,t),t)),[])),i.u=e=>(({78:"page_action-aggregate",147:"metrics-aggregate",242:"session-manager",317:"jserrors-aggregate",348:"page_view_timing-aggregate",412:"lazy-feature-loader",439:"async-api",538:"recorder",590:"session_replay-aggregate",675:"compressor",733:"session_trace-aggregate",786:"page_view_event-aggregate",873:"spa-aggregate",898:"ajax-aggregate"}[e]||e)+"."+{78:"ac76d497",147:"3dc53903",148:"1a20d5fe",242:"2a64278a",317:"49e41428",348:"bd6de33a",412:"2f55ce66",439:"30bd804e",538:"1b18459f",590:"cf0efb30",675:"ae9f91a8",733:"83105561",786:"06482edd",860:"03a8b7a5",873:"e6b09d52",898:"998ef92b"}[e]+"-1.236.0.min.js"),i.o=(e,t)=>Object.prototype.hasOwnProperty.call(e,t),e={},t="NRBA:",i.l=(r,n,o,a)=>{if(e[r])e[r].push(n);else{var s,c;if(void 0!==o)for(var u=document.getElementsByTagName("script"),d=0;d {s.onerror=s.onload=null,clearTimeout(h);var i=e[r];if(delete e[r],s.parentNode&&s.parentNode.removeChild(s),i&&i.forEach((e=>e(n))),t)return t(n)},h=setTimeout(l.bind(null,void 0,{type:"timeout",target:s}),12e4);s.onerror=l.bind(null,s.onerror),s.onload=l.bind(null,s.onload),c&&document.head.appendChild(s)}},i.r=e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})},i.j=364,i.p="https://js-agent.newrelic.com/",(()=>{var e={364:0,953:0};i.f.j=(t,r)=>{var n=i.o(e,t)?e[t]:void 0;if(0!==n)if(n)r.push(n[2]);else{var o=new Promise(((r,i)=>n=e[t]=[r,i]));r.push(n[2]=o);var a=i.p+i.u(t),s=new Error;i.l(a,(r=>{if(i.o(e,t)&&(0!==(n=e[t])&&(e[t]=void 0),n)){var o=r&&("load"===r.type?"missing":r.type),a=r&&r.target&&r.target.src;s.message="Loading chunk "+t+" failed.\n("+o+": "+a+")",s.name="ChunkLoadError",s.type=o,s.request=a,n[1](s)}}),"chunk-"+t,t)}};var t=(t,r)=>{var n,o,[a,s,c]=r,u=0;if(a.some((t=>0!==e[t]))){for(n in s)i.o(s,n)&&(i.m[n]=s[n]);if(c)c(i)}for(t&&t(r);u {i.r(o);var e=i(3325),t=i(5763);const r=Object.values(e.D);function n(e){const n={};return r.forEach((r=>{n[r]=function(e,r){return!1!==(0,t.Mt)(r,"".concat(e,".enabled"))}(r,e)})),n}var a=i(9144);var s=i(5546),c=i(385),u=i(8e3),d=i(5938),f=i(3960),l=i(50);class h extends d.W{constructor(e,t,r){let n=!(arguments.length>3&&void 0!==arguments[3])||arguments[3];super(e,t,r),this.auto=n,this.abortHandler,this.featAggregate,this.onAggregateImported,n&&(0,u.R)(e,r)}importAggregator(){let e=arguments.length>0&&void 0!==arguments[0]?arguments[0]:{};if(this.featAggregate||!this.auto)return;const r=c.il&&!0===(0,t.Mt)(this.agentIdentifier,"privacy.cookies_enabled");let n;this.onAggregateImported=new Promise((e=>{n=e}));const o=async()=>{let t;try{if(r){const{setupAgentSession:e}=await Promise.all([i.e(860),i.e(242)]).then(i.bind(i,3228));t=e(this.agentIdentifier)}}catch(e){(0,l.Z)("A problem occurred when starting up session manager. This page will not start or extend any session.",e)}try{if(!this.shouldImportAgg(this.featureName,t))return void(0,u.L)(this.agentIdentifier,this.featureName);const{lazyFeatureLoader:r}=await i.e(412).then(i.bind(i,8582)),{Aggregate:o}=await r(this.featureName,"aggregate");this.featAggregate=new o(this.agentIdentifier,this.aggregator,e),n(!0)}catch(e){(0,l.Z)("Downloading and initializing ".concat(this.featureName," failed..."),e),this.abortHandler?.(),n(!1)}};c.il?(0,f.b)((()=>o()),!0):o()}shouldImportAgg(r,n){return r!==e.D.sessionReplay||!1!==(0,t.Mt)(this.agentIdentifier,"session_trace.enabled")&&(!!n?.isNew||!!n?.state.sessionReplay)}}var g=i(7633),p=i(7894);class m extends h{static featureName=g.t9;constructor(r,n){let i=!(arguments.length>2&&void 0!==arguments[2])||arguments[2];if(super(r,n,g.t9,i),("undefined"==typeof PerformanceNavigationTiming||c.Tt)&&"undefined"!=typeof PerformanceTiming){const n=(0,t.OP)(r);n[g.Dz]=Math.max(Date.now()-n.offset,0),(0,f.K)((()=>n[g.qw]=Math.max((0,p.z)()-n[g.Dz],0))),(0,f.b)((()=>{const t=(0,p.z)();n[g.OJ]=Math.max(t-n[g.Dz],0),(0,s.p)("timing",["load",t],void 0,e.D.pageViewTiming,this.ee)}))}this.importAggregator()}}var v=i(1117),b=i(1284);class y extends v.w{constructor(e){super(e),this.aggregatedData={}}store(e,t,r,n,i){var o=this.getBucket(e,t,r,i);return o.metrics=function(e,t){t||(t={count:0});return t.count+=1,(0,b.D)(e,(function(e,r){t[e]=w(r,t[e])})),t}(n,o.metrics),o}merge(e,t,r,n,i){var o=this.getBucket(e,t,n,i);if(o.metrics){var a=o.metrics;a.count+=r.count,(0,b.D)(r,(function(e,t){if("count"!==e){var n=a[e],i=r[e];i&&!i.c?a[e]=w(i.t,n):a[e]=function(e,t){if(!t)return e;t.c||(t=x(t.t));return t.min=Math.min(e.min,t.min),t.max=Math.max(e.max,t.max),t.t+=e.t,t.sos+=e.sos,t.c+=e.c,t}(i,a[e])}}))}else o.metrics=r}storeMetric(e,t,r,n){var i=this.getBucket(e,t,r);return i.stats=w(n,i.stats),i}getBucket(e,t,r,n){this.aggregatedData[e]||(this.aggregatedData[e]={});var i=this.aggregatedData[e][t];return i||(i=this.aggregatedData[e][t]={params:r||{}},n&&(i.custom=n)),i}get(e,t){return t?this.aggregatedData[e]&&this.aggregatedData[e][t]:this.aggregatedData[e]}take(e){for(var t={},r="",n=!1,i=0;i t.max&&(t.max=e),e 2&&void 0!==arguments[2])||arguments[2];super(e,r,j.t,n),c.il&&((0,t.OP)(e).initHidden=Boolean("hidden"===document.visibilityState),(0,N.N)((()=>(0,s.p)("docHidden",[(0,p.z)()],void 0,j.t,this.ee)),!0),(0,O.bP)("pagehide",(()=>(0,s.p)("winPagehide",[(0,p.z)()],void 0,j.t,this.ee))),this.importAggregator())}}var P=i(3081);class C extends h{static featureName=P.t9;constructor(e,t){let r=!(arguments.length>2&&void 0!==arguments[2])||arguments[2];super(e,t,P.t9,r),this.importAggregator()}}var R,I=i(2210),k=i(1214),H=i(2177),L={};try{R=localStorage.getItem("__nr_flags").split(","),console&&"function"==typeof console.log&&(L.console=!0,-1!==R.indexOf("dev")&&(L.dev=!0),-1!==R.indexOf("nr_dev")&&(L.nrDev=!0))}catch(e){}function z(e){try{L.console&&z(e)}catch(e){}}L.nrDev&&H.ee.on("internal-error",(function(e){z(e.stack)})),L.dev&&H.ee.on("fn-err",(function(e,t,r){z(r.stack)})),L.dev&&(z("NR AGENT IN DEVELOPMENT MODE"),z("flags: "+(0,b.D)(L,(function(e,t){return e})).join(", ")));var M=i(6660);class B extends h{static featureName=M.t;constructor(r,n){let i=!(arguments.length>2&&void 0!==arguments[2])||arguments[2];super(r,n,M.t,i),this.skipNext=0;try{this.removeOnAbort=new AbortController}catch(e){}const o=this;o.ee.on("fn-start",(function(e,t,r){o.abortHandler&&(o.skipNext+=1)})),o.ee.on("fn-err",(function(t,r,n){o.abortHandler&&!n[M.A]&&((0,I.X)(n,M.A,(function(){return!0})),this.thrown=!0,(0,s.p)("err",[n,(0,p.z)()],void 0,e.D.jserrors,o.ee))})),o.ee.on("fn-end",(function(){o.abortHandler&&!this.thrown&&o.skipNext>0&&(o.skipNext-=1)})),o.ee.on("internal-error",(function(t){(0,s.p)("ierr",[t,(0,p.z)(),!0],void 0,e.D.jserrors,o.ee)})),this.origOnerror=c._A.onerror,c._A.onerror=this.onerrorHandler.bind(this),c._A.addEventListener("unhandledrejection",(t=>{const r=function(e){let t="Unhandled Promise Rejection: ";if(e instanceof Error)try{return e.message=t+e.message,e}catch(t){return e}if(void 0===e)return new Error(t);try{return new Error(t+(0,D.P)(e))}catch(e){return new Error(t)}}(t.reason);(0,s.p)("err",[r,(0,p.z)(),!1,{unhandledPromiseRejection:1}],void 0,e.D.jserrors,this.ee)}),(0,O.m$)(!1,this.removeOnAbort?.signal)),(0,k.gy)(this.ee),(0,k.BV)(this.ee),(0,k.em)(this.ee),(0,t.OP)(r).xhrWrappable&&(0,k.Kf)(this.ee),this.abortHandler=this.#e,this.importAggregator()}#e(){this.removeOnAbort?.abort(),this.abortHandler=void 0}onerrorHandler(t,r,n,i,o){"function"==typeof this.origOnerror&&this.origOnerror(...arguments);try{this.skipNext?this.skipNext-=1:(0,s.p)("err",[o||new F(t,r,n),(0,p.z)()],void 0,e.D.jserrors,this.ee)}catch(t){try{(0,s.p)("ierr",[t,(0,p.z)(),!0],void 0,e.D.jserrors,this.ee)}catch(e){}}return!1}}function F(e,t,r){this.message=e||"Uncaught error with no additional information",this.sourceURL=t,this.line=r}let U=1;const q="nr@id";function G(e){const t=typeof e;return!e||"object"!==t&&"function"!==t?-1:e===c._A?0:(0,I.X)(e,q,(function(){return U++}))}function V(e){if("string"==typeof e&&e.length)return e.length;if("object"==typeof e){if("undefined"!=typeof ArrayBuffer&&e instanceof ArrayBuffer&&e.byteLength)return e.byteLength;if("undefined"!=typeof Blob&&e instanceof Blob&&e.size)return e.size;if(!("undefined"!=typeof FormData&&e instanceof FormData))try{return(0,D.P)(e).length}catch(e){return}}}var X=i(7243);class W{constructor(e){this.agentIdentifier=e,this.generateTracePayload=this.generateTracePayload.bind(this),this.shouldGenerateTrace=this.shouldGenerateTrace.bind(this)}generateTracePayload(e){if(!this.shouldGenerateTrace(e))return null;var r=(0,t.DL)(this.agentIdentifier);if(!r)return null;var n=(r.accountID||"").toString()||null,i=(r.agentID||"").toString()||null,o=(r.trustKey||"").toString()||null;if(!n||!i)return null;var a=(0,_.M)(),s=(0,_.Ht)(),c=Date.now(),u={spanId:a,traceId:s,timestamp:c};return(e.sameOrigin||this.isAllowedOrigin(e)&&this.useTraceContextHeadersForCors())&&(u.traceContextParentHeader=this.generateTraceContextParentHeader(a,s),u.traceContextStateHeader=this.generateTraceContextStateHeader(a,c,n,i,o)),(e.sameOrigin&&!this.excludeNewrelicHeader()||!e.sameOrigin&&this.isAllowedOrigin(e)&&this.useNewrelicHeaderForCors())&&(u.newrelicHeader=this.generateTraceHeader(a,s,c,n,i,o)),u}generateTraceContextParentHeader(e,t){return"00-"+t+"-"+e+"-01"}generateTraceContextStateHeader(e,t,r,n,i){return i+"@nr=0-1-"+r+"-"+n+"-"+e+"----"+t}generateTraceHeader(e,t,r,n,i,o){if(!("function"==typeof c._A?.btoa))return null;var a={v:[0,1],d:{ty:"Browser",ac:n,ap:i,id:e,tr:t,ti:r}};return o&&n!==o&&(a.d.tk=o),btoa((0,D.P)(a))}shouldGenerateTrace(e){return this.isDtEnabled()&&this.isAllowedOrigin(e)}isAllowedOrigin(e){var r=!1,n={};if((0,t.Mt)(this.agentIdentifier,"distributed_tracing")&&(n=(0,t.P_)(this.agentIdentifier).distributed_tracing),e.sameOrigin)r=!0;else if(n.allowed_origins instanceof Array)for(var i=0;i 2&&void 0!==arguments[2])||arguments[2];super(r,n,Z.t,i),(0,t.OP)(r).xhrWrappable&&(this.dt=new W(r),this.handler=(e,t,r,n)=>(0,s.p)(e,t,r,n,this.ee),(0,k.u5)(this.ee),(0,k.Kf)(this.ee),function(r,n,i,o){function a(e){var t=this;t.totalCbs=0,t.called=0,t.cbTime=0,t.end=E,t.ended=!1,t.xhrGuids={},t.lastSize=null,t.loadCaptureCalled=!1,t.params=this.params||{},t.metrics=this.metrics||{},e.addEventListener("load",(function(r){_(t,e)}),(0,O.m$)(!1)),c.IF||e.addEventListener("progress",(function(e){t.lastSize=e.loaded}),(0,O.m$)(!1))}function s(e){this.params={method:e[0]},T(this,e[1]),this.metrics={}}function u(e,n){var i=(0,t.DL)(r);i.xpid&&this.sameOrigin&&n.setRequestHeader("X-NewRelic-ID",i.xpid);var a=o.generateTracePayload(this.parsedOrigin);if(a){var s=!1;a.newrelicHeader&&(n.setRequestHeader("newrelic",a.newrelicHeader),s=!0),a.traceContextParentHeader&&(n.setRequestHeader("traceparent",a.traceContextParentHeader),a.traceContextStateHeader&&n.setRequestHeader("tracestate",a.traceContextStateHeader),s=!0),s&&(this.dt=a)}}function d(e,t){var r=this.metrics,i=e[0],o=this;if(r&&i){var a=V(i);a&&(r.txSize=a)}this.startTime=(0,p.z)(),this.listener=function(e){try{"abort"!==e.type||o.loadCaptureCalled||(o.params.aborted=!0),("load"!==e.type||o.called===o.totalCbs&&(o.onloadCalled||"function"!=typeof t.onload)&&"function"==typeof o.end)&&o.end(t)}catch(e){try{n.emit("internal-error",[e])}catch(e){}}};for(var s=0;s 1?e[1]=i:e.push(i)}else e[0]&&e[0].headers&&s(e[0].headers,n)&&(this.dt=n);function s(e,t){var r=!1;return t.newrelicHeader&&(e.set("newrelic",t.newrelicHeader),r=!0),t.traceContextParentHeader&&(e.set("traceparent",t.traceContextParentHeader),t.traceContextStateHeader&&e.set("tracestate",t.traceContextStateHeader),r=!0),r}}function x(e,t){this.params={},this.metrics={},this.startTime=(0,p.z)(),this.dt=t,e.length>=1&&(this.target=e[0]),e.length>=2&&(this.opts=e[1]);var r,n=this.opts||{},i=this.target;"string"==typeof i?r=i:"object"==typeof i&&i instanceof Y?r=i.url:c._A?.URL&&"object"==typeof i&&i instanceof URL&&(r=i.href),T(this,r);var o=(""+(i&&i instanceof Y&&i.method||n.method||"GET")).toUpperCase();this.params.method=o,this.txSize=V(n.body)||0}function A(t,r){var n;this.endTime=(0,p.z)(),this.params||(this.params={}),this.params.status=r?r.status:0,"string"==typeof this.rxSize&&this.rxSize.length>0&&(n=+this.rxSize);var o={txSize:this.txSize,rxSize:n,duration:(0,p.z)()-this.startTime};i("xhr",[this.params,o,this.startTime,this.endTime,"fetch"],this,e.D.ajax)}function E(t){var r=this.params,n=this.metrics;if(!this.ended){this.ended=!0;for(var o=0;o 2&&void 0!==arguments[2])||arguments[2];super(e,t,we.t,r),this.importAggregator()}}new class{constructor(e){let t=arguments.length>1&&void 0!==arguments[1]?arguments[1]:(0,_.ky)(16);c._A?(this.agentIdentifier=t,this.sharedAggregator=new y({agentIdentifier:this.agentIdentifier}),this.features={},this.desiredFeatures=new Set(e.features||[]),this.desiredFeatures.add(m),Object.assign(this,(0,a.j)(this.agentIdentifier,e,e.loaderType||"agent")),this.start()):(0,l.Z)("Failed to initial the agent. Could not determine the runtime environment.")}get config(){return{info:(0,t.C5)(this.agentIdentifier),init:(0,t.P_)(this.agentIdentifier),loader_config:(0,t.DL)(this.agentIdentifier),runtime:(0,t.OP)(this.agentIdentifier)}}start(){const t="features";try{const r=n(this.agentIdentifier),i=[...this.desiredFeatures];i.sort(((t,r)=>e.p[t.featureName]-e.p[r.featureName])),i.forEach((t=>{if(r[t.featureName]||t.featureName===e.D.pageViewEvent){const n=function(t){switch(t){case e.D.ajax:return[e.D.jserrors];case e.D.sessionTrace:return[e.D.ajax,e.D.pageViewEvent];case e.D.sessionReplay:return[e.D.sessionTrace];case e.D.pageViewTiming:return[e.D.pageViewEvent];default:return[]}}(t.featureName);n.every((e=>r[e]))||(0,l.Z)("".concat(t.featureName," is enabled but one or more dependent features has been disabled (").concat((0,D.P)(n),"). This may cause unintended consequences or missing data...")),this.features[t.featureName]=new t(this.agentIdentifier,this.sharedAggregator)}})),(0,T.Qy)(this.agentIdentifier,this.features,t)}catch(e){(0,l.Z)("Failed to initialize all enabled instrument classes (agent aborted) -",e);for(const e in this.features)this.features[e].abortHandler?.();const r=(0,T.fP)();return delete r.initializedAgents[this.agentIdentifier]?.api,delete r.initializedAgents[this.agentIdentifier]?.[t],delete this.sharedAggregator,r.ee?.abort(),delete r.ee?.get(this.agentIdentifier),!1}}}({features:[J,m,S,class extends h{static featureName=oe;constructor(t,r){if(super(t,r,oe,!(arguments.length>2&&void 0!==arguments[2])||arguments[2]),!c.il)return;const n=this.ee;let i;(0,k.QU)(n),this.eventsEE=(0,k.em)(n),this.eventsEE.on(se,(function(e,t){this.bstStart=(0,p.z)()})),this.eventsEE.on(ae,(function(t,r){(0,s.p)("bst",[t[0],r,this.bstStart,(0,p.z)()],void 0,e.D.sessionTrace,n)})),n.on(ce+ne,(function(e){this.time=(0,p.z)(),this.startPath=location.pathname+location.hash})),n.on(ce+ie,(function(t){(0,s.p)("bstHist",[location.pathname+location.hash,this.startPath,this.time],void 0,e.D.sessionTrace,n)}));try{i=new PerformanceObserver((t=>{const r=t.getEntries();(0,s.p)(te,[r],void 0,e.D.sessionTrace,n)})),i.observe({type:re,buffered:!0})}catch(e){}this.importAggregator({resourceObserver:i})}},C,xe,B,class extends h{static featureName=de;constructor(e,r){if(super(e,r,de,!(arguments.length>2&&void 0!==arguments[2])||arguments[2]),!c.il)return;if(!(0,t.OP)(e).xhrWrappable)return;try{this.removeOnAbort=new AbortController}catch(e){}let n,i=0;const o=this.ee.get("tracer"),a=(0,k._L)(this.ee),s=(0,k.Lg)(this.ee),u=(0,k.BV)(this.ee),d=(0,k.Kf)(this.ee),f=this.ee.get("events"),l=(0,k.u5)(this.ee),h=(0,k.QU)(this.ee),g=(0,k.Gm)(this.ee);function m(e,t){h.emit("newURL",[""+window.location,t])}function v(){i++,n=window.location.hash,this[ve]=(0,p.z)()}function b(){i--,window.location.hash!==n&&m(0,!0);var e=(0,p.z)();this[pe]=~~this[pe]+e-this[ve],this[ye]=e}function y(e,t){e.on(t,(function(){this[t]=(0,p.z)()}))}this.ee.on(ve,v),s.on(be,v),a.on(be,v),this.ee.on(ye,b),s.on(ge,b),a.on(ge,b),this.ee.buffer([ve,ye,"xhr-resolved"],this.featureName),f.buffer([ve],this.featureName),u.buffer(["setTimeout"+le,"clearTimeout"+fe,ve],this.featureName),d.buffer([ve,"new-xhr","send-xhr"+fe],this.featureName),l.buffer([me+fe,me+"-done",me+he+fe,me+he+le],this.featureName),h.buffer(["newURL"],this.featureName),g.buffer([ve],this.featureName),s.buffer(["propagate",be,ge,"executor-err","resolve"+fe],this.featureName),o.buffer([ve,"no-"+ve],this.featureName),a.buffer(["new-jsonp","cb-start","jsonp-error","jsonp-end"],this.featureName),y(l,me+fe),y(l,me+"-done"),y(a,"new-jsonp"),y(a,"jsonp-end"),y(a,"cb-start"),h.on("pushState-end",m),h.on("replaceState-end",m),window.addEventListener("hashchange",m,(0,O.m$)(!0,this.removeOnAbort?.signal)),window.addEventListener("load",m,(0,O.m$)(!0,this.removeOnAbort?.signal)),window.addEventListener("popstate",(function(){m(0,i>1)}),(0,O.m$)(!0,this.removeOnAbort?.signal)),this.abortHandler=this.#e,this.importAggregator()}#e(){this.removeOnAbort?.abort(),this.abortHandler=void 0}}],loaderType:"spa"})})(),window.NRBA=o})(); window.jQuery || document.write(' ') CKEDITOR_BASEPATH='https://f1000research.com/js/vendor/ckeditor/' window.reactTheme = 'research'; window.MathJax = { CommonHTML: { linebreaks: { automatic: true } }, 'HTML-CSS': { linebreaks: { automatic: true } }, SVG: { linebreaks: { automatic: true } }, AuthorInit: function() { MathJax.Hub.Register.MessageHook('End Process', function () { let timeout = false; // holder for timeout id const delay = 250; // delay after event is "complete" to run callback const reflowMath = function() { const dispFormulas = document.querySelectorAll('.disp-formula.panel'); if (!dispFormulas) { return; } for (const dispFormula of dispFormulas) { const child = dispFormula.querySelector('.MathJax_Preview').nextSibling.firstChild; const isMultiline = MathJax.Hub.getAllJax(dispFormula)[0].root.isMultiline; if (dispFormula.offsetWidth < child.offsetWidth || isMultiline) { MathJax.Hub.Queue(['Rerender', MathJax.Hub, dispFormula]); } } }; window.addEventListener('resize', function() { clearTimeout(timeout); // clear the timeout timeout = setTimeout(reflowMath, delay); // start timing for event "completion" }); }); }, }; if (window.location.hash == '#_=_'){ window.location = window.location.href.split('#')[0] } !function(f,b,e,v,n,t,s){if(f.fbq)return;n=f.fbq=function() {n.callMethod? n.callMethod.apply(n,arguments):n.queue.push(arguments)} ;if(!f._fbq)f._fbq=n; n.push=n;n.loaded=!0;n.version='2.0';n.queue=[];t=b.createElement(e);t.async=!0; t.src=v;s=b.getElementsByTagName(e)[0];s.parentNode.insertBefore(t,s)}(window, document,'script','https://connect.facebook.net/en_US/fbevents.js'); fbq('init', '1641728616063202'); fbq('track', "PixelInitialized", {}); (function(h,o,t,j,a,r){ h.hj=h.hj||function(){(h.hj.q=h.hj.q||[]).push(arguments)}; h._hjSettings={hjid:2318163,hjsv:6}; a=o.getElementsByTagName('head')[0]; r=o.createElement('script');r.async=1; r.src=t+h._hjSettings.hjid+j+h._hjSettings.hjsv; a.appendChild(r); })(window,document,'https://static.hotjar.com/c/hotjar-','.js?sv='); search file_upload Submit your research search menu close search Browse Gateways & Collections How to Publish Submit your Research My Submissions Article Guidelines Article Guidelines (New Versions) Open Data, Software and Code Guidelines Open Data and Accessible Source Materials Guidelines (HSS) Open Data, Software and Code Guidelines (PSE) Prepublication Checks Production Process Posters and Slides Guidelines Document Guidelines Article Processing Charges Peer Review Finding Article Reviewers About How it Works For Reviewers Our Advisors Policies Glossary FAQs For Developers Newsroom Contact My Research Submissions Content and Tracking Alerts My Details Sign In file_upload Submit your research { "@context": "https://schema.org", "@type": "ScholarlyArticle", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://f1000research.com/articles/12-118" }, "headline": "Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical...", "datePublished": "2023-02-01T14:31:13", "dateModified": "2025-02-07T08:19:24", "author": [ { "@type": "Person", "name": "Sejin Kim" }, { "@type": "Person", "name": "Michal Kazmierski" }, { "@type": "Person", "name": "Kevin Qu" }, { "@type": "Person", "name": "Jacob Peoples" }, { "@type": "Person", "name": "Minoru Nakano" }, { "@type": "Person", "name": "Vishwesh Ramanathan" }, { "@type": "Person", "name": "Joseph Marsilla" }, { "@type": "Person", "name": "Mattea Welch" }, { "@type": "Person", "name": "Amber Simpson" }, { "@type": "Person", "name": "Benjamin Haibe-Kains" } ], "publisher": { "@type": "Organization", "name": "F1000Research", "logo": { "@type": "ImageObject", "url": "https://f1000research.com/img/AMP/F1000Research_image.png", "height": 480, "width": 60 } }, "image": { "@type": "ImageObject", "url": "https://f1000research.com/img/AMP/F1000Research_image.png", "height": 1200, "width": 150 }, "description": " Background Machine learning and AI promise to revolutionize the way we leverage medical imaging data for improving care but require large datasets to train computational models that can be implemented in clinical practice. However, processing large and complex medical imaging datasets remains an open challenge. Methods To address this issue, we developed Med-ImageTools, a new Python open-source software package to automate data curation and processing while allowing researchers to share their data processing configurations more easily, lowering the barrier for other researchers to reproduce published works. Use cases We have demonstrated the efficiency of Med-ImageTools across three different datasets, resulting in significantly reduced processing times. Conclusions The AutoPipeline feature will improve the accessibility of raw clinical datasets on public archives, such as the Cancer Imaging Archive (TCIA), the largest public repository of cancer imaging, allowing machine learning researchers to process analysis-ready formats without requiring deep domain knowledge. " } { "@context": "http://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": "1", "item": { "@id": "https://f1000research.com/", "name": "Home" } }, { "@type": "ListItem", "position": "2", "item": { "@id": "https://f1000research.com/browse/articles", "name": "Browse" } }, { "@type": "ListItem", "position": "3", "item": { "@id": "https://f1000research.com/articles/12-118/v3", "name": "Med-ImageTools: An open-source Python package for robust data processing..." } } ] } Home Browse Med-ImageTools: An open-source Python package for robust data processing... ALL Metrics - Views Downloads Get PDF Get XML Cite How to cite this article Kim S, Kazmierski M, Qu K et al. Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data [version 3; peer review: 2 approved] . F1000Research 2025, 12 :118 ( https://doi.org/10.12688/f1000research.127142.3 ) NOTE: If applicable, it is important to ensure the information in square brackets after the title is included in all citations of this article. Close Copy Citation Details Export Export Citation Sciwheel EndNote Ref. Manager Bibtex ProCite Sente EXPORT Select a format first Track Share ▬ ✚ Software Tool Article Revised Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data [version 3; peer review: 2 approved] Sejin Kim 1,2 , Michal Kazmierski 1,2 , Kevin Qu https://orcid.org/0000-0002-5936-3581 1,3 , [...] Jacob Peoples https://orcid.org/0000-0003-0191-7446 4 , Minoru Nakano 1 , Vishwesh Ramanathan 2 , Joseph Marsilla 1,2 , Mattea Welch 1 , Amber Simpson 4,5 , Benjamin Haibe-Kains 1,2,4,5 Sejin Kim 1,2 , Michal Kazmierski 1,2 , [...] Kevin Qu https://orcid.org/0000-0002-5936-3581 1,3 , Jacob Peoples https://orcid.org/0000-0003-0191-7446 4 , Minoru Nakano 1 , Vishwesh Ramanathan 2 , Joseph Marsilla 1,2 , Mattea Welch 1 , Amber Simpson 4,5 , Benjamin Haibe-Kains 1,2,4,5 PUBLISHED 07 Feb 2025 Author details Author details 1 Princess Margaret Cancer Centre, University Health Network, Canada, Toronto, ON, Canada 2 Department of Medical Biophysics, University of Toronto, Toronto, ON, Canada 3 Faculty of Engineering, University of Toronto, Toronto, ON, Canada 4 Centre for Health Innovation, Queen's University and Kingston Health Science Centre, Kingston, ON, Canada 5 Vector Institute, Toronto, ON, Canada Sejin Kim Roles: Conceptualization, Data Curation, Formal Analysis, Investigation, Methodology, Project Administration, Software, Validation, Visualization, Writing – Original Draft Preparation, Writing – Review & Editing Michal Kazmierski Roles: Conceptualization, Methodology, Software Kevin Qu Roles: Data Curation, Methodology, Software, Validation Jacob Peoples Roles: Conceptualization, Data Curation, Methodology, Validation, Writing – Review & Editing Minoru Nakano Roles: Resources, Software Vishwesh Ramanathan Roles: Methodology, Software, Validation Joseph Marsilla Roles: Methodology, Validation Mattea Welch Roles: Conceptualization, Methodology, Resources, Supervision Amber Simpson Roles: Resources, Supervision, Writing – Review & Editing Benjamin Haibe-Kains Roles: Conceptualization, Funding Acquisition, Methodology, Project Administration, Resources, Supervision, Writing – Review & Editing OPEN PEER REVIEW DETAILS REVIEWER STATUS This article is included in the Bioinformatics gateway. This article is included in the Python collection. This article is included in the Radiomics collection. Abstract Background Machine learning and AI promise to revolutionize the way we leverage medical imaging data for improving care but require large datasets to train computational models that can be implemented in clinical practice. However, processing large and complex medical imaging datasets remains an open challenge. Methods To address this issue, we developed Med-ImageTools, a new Python open-source software package to automate data curation and processing while allowing researchers to share their data processing configurations more easily, lowering the barrier for other researchers to reproduce published works. Use cases We have demonstrated the efficiency of Med-ImageTools across three different datasets, resulting in significantly reduced processing times. Conclusions The AutoPipeline feature will improve the accessibility of raw clinical datasets on public archives, such as the Cancer Imaging Archive (TCIA), the largest public repository of cancer imaging, allowing machine learning researchers to process analysis-ready formats without requiring deep domain knowledge. READ ALL READ LESS Keywords medical imaging, deep learning, open source, data processing, dicom, nifti, nnunet Corresponding Author(s) Benjamin Haibe-Kains ( [email protected] ) Close Corresponding author: Benjamin Haibe-Kains Competing interests: No competing interests were disclosed. Grant information: This study has been supported by the Canadian Institutes for Health Research (Project Scheme grant #426366) and the Canadian Cancer Society (Data Transformation grant #707609). The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript. Copyright: © 2025 Kim S et al . This is an open access article distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. How to cite: Kim S, Kazmierski M, Qu K et al. Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data [version 3; peer review: 2 approved] . F1000Research 2025, 12 :118 ( https://doi.org/10.12688/f1000research.127142.3 ) First published: 01 Feb 2023, 12 :118 ( https://doi.org/10.12688/f1000research.127142.1 ) Latest published: 07 Feb 2025, 12 :118 ( https://doi.org/10.12688/f1000research.127142.3 ) Revised Amendments from Version 2 Updated DOI and Documentation URLs, after streamlining CI-CD pipelines based on user/reviewer feedback. Updated DOI and Documentation URLs, after streamlining CI-CD pipelines based on user/reviewer feedback. See the authors' detailed response to the review by Rachel Sparks See the authors' detailed response to the review by Johann Faouzi READ REVIEWER RESPONSES Introduction Radiology is a powerful modality of data for clinical work — it gives clinicians the ability to see the inner workings of the human body, that cannot be seen from the outside. 1 They can inspect in 2D or 3D, the anatomy surrounding the disease, enabling key information to make life-altering clinical decisions. While regular images taken on cameras or phones are stored in a variety of accessible formats, medical images are encoded in the Digital Imaging and Communications in Medicine (DICOM) standard file format. 2 The DICOM standard was developed in the 1980s due to the increasing need for an interoperable standard for 3D medical images across various manufacturers. 2 A key feature of DICOM is the plethora of metadata fields that store information beyond imaging data, such as patient information, clinical variables, and acquisition parameters. As modern medical practice evolved over the years, the DICOM standard has grown to accommodate more metadata fields and encompass new imaging modalities or therapy information. 2 This type of data format is unsuitable for imaging analysis as the relevant voxel array must be manually accessed through DICOM hierarchy. 2 Furthermore, 3D scans are acquired on a slice-by-slice basis; thus, researchers must stitch together data from multiple files to create one 3D image, adding delays caused by disk reads and consolidation processes. 2 Specialties that rigorously use imaging data are heavily reliant on DICOM, one of which is radiation oncology. Images are used along every step of the clinical workflow: from deriving a precise diagnosis, to designing personalized radiation therapy plans, and delivering each radiation dose with the appropriate alignment and orientation with brief scans. While the defined standard serves as a good guideline, each manufacturer has slightly different implementations. This is especially the case for DICOM-RT (radiotherapy), a subset of modalities for communicating radiotherapy data. 2 The DICOM-RT standard includes additional modalities such as RTStruct for contour data, and RTDose for radiotherapy dose maps and dose-volume histograms (DVH). 2 While the broad adoption of the DICOM standard to accommodate for various use cases has allowed it to become the defacto standard for encoding, storing, and transferring of medical images, its comprehensive nature has made it difficult for researchers to navigate for the purposes of imaging projects. 2 Current workflows The Cancer Imaging Archive (TCIA) (RRID:SCR_008927) is one of the largest public repositories of DICOM images available, with over 140 datasets consisting of more than 60,000 patients. 3 The datasets undergo a quality assurance process to ensure the recorded clinical variables are coherent and the DICOM files are not missing any important metadata fields. 3 These stringent processes and infrastructure have allowed TCIA to become one of the most comprehensive repositories for biomedical imaging datasets, inviting researchers from different fields to explore new ideas and methods on high quality datasets. 3 While the underlying data and its annotations are of clinical quality, processing the dataset for subsequent analysis requires a non-trivial amount of effort: manually reorganizing directories and matching radiation therapy structures (RTStruct), referred to as DICOM-RT contours, and radiation therapy plans (RTDose/RTPlan) to its corresponding images. 4 This is partly due to the inherently complex nature of clinical datasets, as data is collected on the basis of need and iterative improvements, not structured scientific inquiries. It is also sometimes due to the lack of familiarity from machine learning (ML) and artificial intelligence (AI) researchers in handling the DICOM files for their analytical pipelines. Typical AI imaging datasets have pairwise associations of one image to a single ground-truth label. 5 However, one patient in clinical datasets may have multiple RTStruct and RTDose files with one imaging acquisition, one RTStruct and RTDose with multiple images, or worst of all, multiple RTStruct and RTDose files with multiple images. 6 In any of these cases, the directories are not always intuitively structured to help researchers understand which files correspond with another. Once researchers have successfully curated the dataset into an organized structure for analysis, in order to process the raw dataset into analysis-ready format, they must choose from a variety of processing parameters, ranging from voxel spacing, RTStruct name parsing, and hounsfield unit (HU) window levels, based on the design of their analysis. While these implicit decisions for image processing are often arbitrary, they can greatly impact model training and performance, but are not transparently disclosed in publications. 7 This leads to the difficulty of reproducibility of medical deep learning research, adding another deterrence to clinical adoption. Furthermore, there are a limited number of software packages that researchers can use to quickly parse DICOM-RT files into analysis-ready arrays ( Table 1 ). Chief among those, SlicerRT, 8 an extension of 3Dslicer 9 (RRID:SCR_005619), an open-source DICOM visualization tool, has been widely used by the medical imaging community. Despite its broad adoption, batch data processing with Slicer requires custom scripting in Python, to be executed in the Slicer ecosystem. Rather than simply installing a package within their Python environment, users must install the Slicer application and add any other dependencies, not provided by Slicer, into the application environment. As a result, machine learning projects relying on Python for data preprocessing will have their code fragmented across multiple environments–the Slicer environment for data processing, and another Python environment for data analysis and machine learning. 10 RT-Utils is a lightweight, open-source Python package designed to handle RTStruct files with relative ease and simplicity, allowing users to easily export contours into segmentation masks in arrays. However, the functionalities of RT-Utils are limited to the RTStruct modality. PlatiPy is a recent processing library and analysis toolkit for medical imaging, mainly designed for the context of radiation therapy. It features a comprehensive set of image manipulation functions such as registration and atlas-based segmentation methods, allowing researchers the flexibility to process imaging data into any format they need. However, PlatiPy does not solve the inherent complexity of clinical datasets, and researchers must spend hours reorganizing the data into a structured set of samples and labels. The current landscape of open-source medical imaging tools highlights the need for a native Python package that can parse large DICOM/DICOM-RT datasets to an analysis-ready format for ML/AI development in a consistent, reproducible workflow. Table 1. Comparison of existing medical imaging processing packages and their features. RTSTRUCTs: DICOM-RT Contours; RTDOSEs: DICOM-RT Dose; CT: Computed Tomography; MRI: Magnetic Resonance Imaging; NifTI: Neuroimaging Informatics Technology Initiative; Nrrd: Nearly raw raster data; DICOM: Digital Imaging and Communications in Medicine. 3Dslicer + SlicerRT RT-Utils PlatiPy Med-ImageTools Native Python interface ⬤ ⬤ ⬤ Command-line interface ⬤ Handles RTSTRUCTs ⬤ ⬤ ⬤ ⬤ Handles RTDOSEs ⬤ ⬤ ⬤ Handles images (CT/MRI) ⬤ ⬤ ⬤ Built-in image transformations ⬤ ⬤ ⬤ Exports to analysis-ready NifTI/Nrrd ⬤ ⬤ ⬤ Image registration ⬤ ⬤ Built-in bulk processing of entire datasets ⬤ Automatic parsing of DICOM metadata ⬤ ⬤ To address the limitations of the current software packages used to process medical images, we developed Med-ImageTools, 11 a new Python package designed to help researchers transform complex medical datasets into analysis-ready format with few lines of code. It is also focused on helping researchers develop transparent and reproducible medical image processing pipelines by addressing most of the boilerplate code required for image transformations and processing parallelization. While Med-ImageTools has many modular functions for image, contour, and dose input/output (IO) built on popular frameworks such as SimpleITK, TorchIO and PyDicom, such functionalities are redundant and available in other open-source packages as well. We have tailored our core features towards broader use cases and development workflows, instead of modality or disease type specific workflows, such as BIDS. 12 Our main contribution is in the development of AutoPipeline and will mainly discuss its functionalities and implementation. Methods AutoPipeline AutoPipeline is the main feature of Med-ImageTools that allows users to easily process raw DICOM clinical datasets into analysis-ready Nrrd or NifTI files, which are commonly used file formats for 3D volumetric data. It is interfaced using the command line, so the user only needs to submit a single command into the terminal to execute the three core steps in the AutoPipeline process ( Figure 1 ): 1. Crawl : The crawler opens every DICOM file in the dataset using Pydicom, indexing important metadata, such as unique identifiers, modality information, and references to other modalities. This produces a database of every unique image and DICOM-RT modality. 2. Connect : In this step, each patient’s indices of unique files of different modalities are connected to form one coherent sample. There are various heuristics the user may choose to connect samples. The default option is through DICOM metadata, as datasets derived from clinical practice are expected to have corresponding metadata that references unique identifiers of the parent image or RTPlan. Alternative heuristics allow users to deal with anomalies with corrupted or missing metadata. 3. Process : All identified samples are processed according to imaging and transformation parameters defined by the user. The user can configure parameters such as the pixel spacing in mm(s), which specific modalities to process, the number of cores they want to use for multiprocessing, and define nnU-Net specific flags as well. The images are manipulated using SimpleITK without requiring any user intervention. Figure 1. Overview of Med-ImageTools features. Raw datasets are indexed by the Crawler module and automatically processed by AutoPipeline. DICOM: Digital Imaging and Communications in Medicine; RTSTRUCTs: DICOM-RT Contours; PET: Positron emission tomography. NifTI: Neuroimaging Informatics Technology Initiative; CSV: Comma-separated values. The AutoPipeline feature can be directly interfaced once Med-ImageTools is installed. To install Med-ImageTools, the recommended method is via the PyPI package repository in a virtual environment. Running the ‘ pip install med-imagetools ’ command will install the latest version of Med-ImageTools and its associated dependencies defined by the requirements.txt file. Now, whenever the user is in the virtual environment where Med-ImageTools is installed, they can directly interact with the AutoPipeline feature in the command line. The simplest way to use it is through ‘ autopipeline input_directory output_directory ’. This will automatically process the dataset located in ‘ input_directory ’ and process them at ‘ output_directory ’ using the default parameters. Med-ImageTools will generate files that are not analysis-ready images, such as the autogenerated ‘Dataset Index’ ( Figure 1 ), and store them in a folder named “.imgtools” at the path of the ‘input_directory’. This is to ensure a convenient user experience and intuitive folder structure by hiding extraneous components. An extended tutorial of AutoPipeline and all its associated parameters are available here . At the present time, there are no minimum system requirements for Med-ImageTools as it will run regardless of number of processor cores or memory (RAM). However, if the researcher can leverage greater number of cores and RAM, it will allow the AutoPipeline to be parallelized and process the data faster. As the crawl and process steps are computationally intensive, all steps in AutoPipeline are automatically parallelized using the joblib backend to efficiently leverage all available computational resources. While the output of the AutoPipeline processing can result in terabytes of images, the crawl is limited to a few kilobytes of a metadata database, making it an ideal asset to share with other researchers as a detailed descriptor of a medical imaging dataset. We therefore propose to attach the crawled metadata spreadsheet to large TCIA datasets to allow Med-ImageTools users to process large datasets much faster and more efficiently. These databases are expected to save up to 1000 core-hours of crawling per dataset, accumulating over 2000 core-hours of computation saved per user. By standardizing a commonly repeated imaging processing pipeline into a single unified package, we hope to improve the reproducibility and transparency of future medical imaging research. Use cases We showcase the value of the AutoPipeline implemented in Med-ImageTools v1.0.0 for processing three medical imaging datasets, namely Pancreatic-CBCT-SEG from TCIA, liver metastasis private dataset and RADCURE pending public release on TCIA, in order of complexity and sizes. In each use case, we initially describe the process. Using pre-crawled datasets on the Pancreatic Cone-beam Computed Tomography (CBCT) 13 40 patients with abdominal CBCT scans and their associated contours of regions of interest and other organs, publicly available on TCIA The Pancreatic-CT-CBCT-SEG dataset was processed twice using AutoPipeline: once from scratch, and once using the pre-crawled dataset, available on the tcia-crawls branch of Med-ImageTools. Processing from scratch, the dataset took 10.77 core-hours (10:46), whereas using a pre-crawled database allowed the processing to finish in 9.14 core-hours (9:08) ( Figure 2a ). The pre-crawled database reduced processing time by 1.63 core-hours, representing an 18% increase in total processing speed or 2 minutes 27 seconds per patient. The time saved from pre-crawled databases is not a substantial quantity for datasets with less than 100 patients. However, when scaled up to larger TCIA datasets such as OPC-Radiomics 14 (n=606) and NLST 15 (n=26254), it can save researchers 24.7 core-hours and 1072 core-hours, respectively ( Figure 2b ). The resources saved are reported in core-hours to allow a hardware-agnostic estimation of time and cost savings. While it may vary depending on the research infrastructure utilized, these databases can result in significant savings in billing. Figure 2. a) Time taken to process the Pancreatic-CT-CBCT-SEG dataset with (Pre-crawl) and without (Default) the pre-crawled databases. b) Amount of core-hours saved by using pre-crawled databases across various public TCIA datasets. c) Time taken to process the liver metastasis dataset manually vs AutoPipeline. d) Time taken to process the RADCURE dataset manually vs AutoPipeline. Comparing manual vs automatic processing of the liver metastasis dataset 97 patients with abdominal CT scans and their associated contours of liver and gross tumour volumes (GTV), data access described in data availability section below. The liver metastasis dataset was processed using the Slicer API to export a CT scan along with segmentations of the liver and GTVs for each patient. In the initial DICOM dataset, each patient had a single RTSTRUCT file along with one or more CT series, one of which was referenced by the RTSTRUCT. The first step of the process was to load the entire DICOM dataset into the Slicer DICOM database via the graphical user interface (GUI), to make the data available inside the Slicer scripting environment. Then, we wrote a script to export an initial set of candidate segmentations for the liver and GTVs for each patient, along with the referenced CT scan. This script leveraged the Slicer API to identify the CT series that was referenced by the patient’s RTSTRUCT and used an ad hoc string filtering function to identify candidate segmentations. Finally, we iteratively refined the set of exported RTSTRUCT contours on a patient-by-patient basis, based on visual checking, and physician feedback. Although this step was time-consuming, there is, at present, no substitute for manual verification to ensure data quality and correctness. On the other hand, the initial database construction and export script using the Slicer API achieved results roughly analogous to the automatic output of AutoPipeline. The export script is approximately 170 lines long and took 7.5 hours to run on the whole dataset-this script is available on our GitHub repository. In contrast, on the same 6-core machine (16GB RAM, Windows 10), AutoPipeline took only 2.3 hours with 1 command line, mainly accelerated by parallelization ( Figure 2c ). The authors involved in validating Med-ImageTools’ effectiveness on this private dataset had no active involvement in the development of the package before its application. This highlights the package’s robustness on unseen data and its potential utility for multi-centre collaborations to ensure consistent processing. One use case might be to enable federated learning platforms to automatically process each node’s datasets without requiring any user intervention. Comparing manual vs automatic processing of the RADCURE dataset 3,219 patients with head and neck CT scans and their associated contours of organs at risk (OAR) for radiotherapy, pending public release on TCIA. The RADCURE dataset is a large dataset of 3,219 head and neck cancer patients and their radiotherapy planning data. The dataset was extracted from two separate treatment planning software systems, meaning the directories and DICOM metadata were structured differently. The directories from each system were restructured using general heuristics, and any abnormal cases were flagged and manually organized. We used SimpleITK and PyDicom to extract the imaging and contour data from the DICOM files, which underwent a similar iterative process as the liver metastatic dataset. The script is over 1000 lines long and takes 30-40 hours to run on the whole dataset using a single core-this script is available on our GitHub repository. AutoPipeline scales dramatically based on the number of cores available, which enables the entire dataset to be processed in 40 minutes using 32 cores, automatically managing the directories from different systems and extracting the contours ( Figure 2d ). These results demonstrate Med-ImageTools’ design does not bottleneck any multiprocessing backends and brings meaningful acceleration on very large datasets, such as RADCURE. One caveat of these comparisons is that the iterative process of filtering appropriate contours, which can add weeks to months of cooperation between the researchers and the physicians, were already conducted in the original processing steps. Various data cleaning steps that require human intervention, such as sorting contour names or selecting specific subseries acquisitions, cannot be fully automated for the foreseeable future. The Med-ImageTools team aims to add features to the package that will assist researchers in these steps, such as adding a flag to visualize all unique contours without requiring code, adding subseries detection to the crawler, and publishing a set of regular expressions (regex) that can be used to automatically choose contours from prominent head and neck datasets on TCIA. Also, these comparisons do not take into account the time it takes for researchers to develop the manual processing scripts. Hence, the actual amount of time saved for the researcher may be greater than the reported times. Discussion Although ML and AI promise to revolutionize the way we leverage medical imaging data for improving care, they require large datasets to train computational models that can be implemented in clinical practice. However, processing large and complex medical imaging datasets remains an open challenge. To address this issue, we developed Med-ImageTools, a new open-source software package to automate data curation and processing while allowing researchers to share their data processing configurations more easily, lowering the barrier for other researchers to reproduce published works. The AutoPipeline feature will improve the accessibility of raw clinical datasets on public archives, such as TCIA, allowing machine learning researchers to process analysis-ready formats without requiring deep domain knowledge. Another exciting potential of Med-ImageTools lies in building automated workflows using AutoPipeline. For a researcher to build an end-to-end automated pipeline starting from clinical DICOM datasets to outputting an inference-ready deep learning model, they could easily develop a reproducible processing step by configuring only the command line interaction of Med-ImageTools, making debugging and custom configurations simpler since the developer would not have to rely on a static script. While our package aims to address challenges encountered across a few medical imaging labs, we acknowledge that there may be infinite other issues that may arise in DICOM datasets. This is one of the key reasons why our package is open-source for community involvement and contribution. Also, as stated previously, there are certain onerous tasks that cannot be automated and must undergo human supervision. These aspects of researcher-clinician collaboration are an inevitable part of medical imaging research and are subject to delay. No single solution can completely solve the reproducibility crisis of medical deep learning research, due to a variety of issues ranging from ambiguous data processing techniques to stochasticity of model training. However, community-centered open-source solutions and increased clinical adherence to data standards, such as contour nomenclature, 16 can incrementally improve research quality and reproducibility, and make medical deep learning research more accessible for everyone. Data availability The Pancreatic-CT-CBCT-SEG dataset is available on The Cancer Imaging Archive at: https://doi.org/10.7937/TCIA.ESHQ-4D90 . The pre-crawled Med-ImageTools database of the Pancreatic-CT-CBCT-SEG dataset is available on GitHub at: https://github.com/bhklab/med-imagetools/raw/tcia-crawls/csvs/imgtools_Pancreatic-CT-CBCT-SEG.csv . The liver dataset was collected as part of the study titled Radiomics artificial intelligence modelling for prediction of local control for colorectal liver metastases treated with radiotherapy 17 with Institutional Review Board and informed consent. Interested individuals should contact the senior author for access to the dataset, which will be made available following standard institutional rules for IRB and HIPAA. The RADCURE dataset is pending public release on TCIA and the article will be updated upon release. Data published on TCIA are subject to TCIA data usage policies and restrictions. Software availability Source code available from: github.com/bhklab/med-imagetools also available on the PyPI software repository: pypi.org/project/med-imagetools . Scripts for use cases are available from: github.com/bhklab/med-imagetools/tree/F1000Research Archived source code at time of publication: https://doi.org/10.5281/zenodo.14766792 18 License: MIT Its associated documentation and tutorials are available at: https://bhklab.github.io/med-imagetools References 1. Brant WE, Helms CA: Fundamentals of Diagnostic Radiology.2012. 2. Mildenberger P, Eichelberg M, Martin E: Introduction to the DICOM standard. Eur. Radiol. 2002; 12 : 920–927. PubMed Abstract | Publisher Full Text 3. Clark K, et al. : The Cancer Imaging Archive (TCIA): maintaining and operating a public information repository. J. Digit. Imaging. 2013; 26 : 1045–1057. PubMed Abstract | Publisher Full Text | Free Full Text 4. Law MYY, Liu B: DICOM-RT and Its Utilization in Radiation Therapy. RadioGraphics. 2009; 29 : 655–667. PubMed Abstract | Publisher Full Text 5. Deng J, et al. : ImageNet: A large-scale hierarchical image database. In 2009 IEEE Conference on Computer Vision and Pattern Recognition. 2009; pp. 248–255. Publisher Full Text 6. Vallières M, Kay-Rivest E, et al. : Data from Head-Neck-PET-CT. The Cancer Imaging Archive. 2017. Publisher Full Text 7. Sabottke CF, Spieler BM: The Effect of Image Resolution on Deep Learning in Radiography. Radiol. Artif. Intell. 2020; 2 : e190015. 8. Pinter C, Lasso A, Wang A, et al. : SlicerRT: radiation therapy research toolkit for 3D Slicer. Med. Phys. 2012; 39 : 6332–6338. PubMed Abstract | Publisher Full Text 9. Fedorov A, et al. : 3D Slicer as an image computing platform for the Quantitative Imaging Network. Magn. Reson. Imaging. 2012; 30 : 1323–1341. PubMed Abstract | Publisher Full Text | Free Full Text 10. Yli-Heikkilä M: Data Science Languages. DSNS '19. University of Helsinki; 2019. 11. Kazmierski M, Kim S, Ramanathan V, et al. : bhklab/med-imagetools: v4.4.0. Zenodo. 2022. Publisher Full Text 12. Gorgolewski K, Auer T, Calhoun VD, et al. : The brain imaging data structure, a format for organizing and describing outputs of neuroimaging experiments. Sci. Data. 2016; 3 : 160044. PubMed Abstract | Publisher Full Text | Free Full Text 13. Camp B: Pancreatic-CT-CBCT-SEG - The Cancer Imaging Archive (TCIA) Public Access - Cancer Imaging Archive Wiki. Publisher Full Text 14. Kwan JYY, et al. : Radiomic Biomarkers to Refine Risk Models for Distant Metastasis in HPV-related Oropharyngeal Carcinoma. Int. J. Radiat. Oncol. Biol. Phys. 2018; 102 : 1107–1116. PubMed Abstract | Publisher Full Text 15. Clark K: National Lung Screening Trial. Publisher Full Text 16. Mayo CS, et al. : American Association of Physicists in Medicine Task Group 263: Standardizing Nomenclatures in Radiation Oncology. Int. J. Radiat. Oncol. Biol. Phys. 2018; 100 : 1057–1066. PubMed Abstract | Publisher Full Text | Free Full Text 17. Hu R, Chen I, et al. : Radiomics artificial intelligence modelling for prediction of local control for colorectal liver metastases treated with radiotherapy. Phys. Imaging Radiat. Oncol. 2022; 24 : 36–42. PubMed Abstract | Publisher Full Text | Free Full Text 18. Cranmer K, Kreiss S: decouple software associated to arXiv:1401.0080. [Code] Zenodo. 2014. Publisher Full Text Comments on this article Comments (0) Version 3 VERSION 3 PUBLISHED 01 Feb 2023 ADD YOUR COMMENT Comment Author details Author details 1 Princess Margaret Cancer Centre, University Health Network, Canada, Toronto, ON, Canada 2 Department of Medical Biophysics, University of Toronto, Toronto, ON, Canada 3 Faculty of Engineering, University of Toronto, Toronto, ON, Canada 4 Centre for Health Innovation, Queen's University and Kingston Health Science Centre, Kingston, ON, Canada 5 Vector Institute, Toronto, ON, Canada Sejin Kim Roles: Conceptualization, Data Curation, Formal Analysis, Investigation, Methodology, Project Administration, Software, Validation, Visualization, Writing – Original Draft Preparation, Writing – Review & Editing Michal Kazmierski Roles: Conceptualization, Methodology, Software Kevin Qu Roles: Data Curation, Methodology, Software, Validation Jacob Peoples Roles: Conceptualization, Data Curation, Methodology, Validation, Writing – Review & Editing Minoru Nakano Roles: Resources, Software Vishwesh Ramanathan Roles: Methodology, Software, Validation Joseph Marsilla Roles: Methodology, Validation Mattea Welch Roles: Conceptualization, Methodology, Resources, Supervision Amber Simpson Roles: Resources, Supervision, Writing – Review & Editing Benjamin Haibe-Kains Roles: Conceptualization, Funding Acquisition, Methodology, Project Administration, Resources, Supervision, Writing – Review & Editing Competing interests No competing interests were disclosed. Grant information This study has been supported by the Canadian Institutes for Health Research (Project Scheme grant #426366) and the Canadian Cancer Society (Data Transformation grant #707609). The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript. Article Versions (3) version 3 Revised Published: 07 Feb 2025, 12:118 https://doi.org/10.12688/f1000research.127142.3 version 2 Revised Published: 07 May 2024, 12:118 https://doi.org/10.12688/f1000research.127142.2 version 1 Published: 01 Feb 2023, 12:118 https://doi.org/10.12688/f1000research.127142.1 Copyright © 2025 Kim S et al . This is an open access article distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. Download Export To Sciwheel Bibtex EndNote ProCite Ref. Manager (RIS) Sente metrics Views Downloads F1000Research - - PubMed Central info_outline Data from PMC are received and updated monthly. - - Citations open_in_new 0 open_in_new 0 open_in_new SEE MORE DETAILS CITE how to cite this article Kim S, Kazmierski M, Qu K et al. Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data [version 3; peer review: 2 approved] . F1000Research 2025, 12 :118 ( https://doi.org/10.12688/f1000research.127142.3 ) NOTE: If applicable, it is important to ensure the information in square brackets after the title is included in all citations of this article. COPY CITATION DETAILS track receive updates on this article Track an article to receive email alerts on any updates to this article. TRACK THIS ARTICLE Share Open Peer Review Current Reviewer Status: ? Key to Reviewer Statuses VIEW HIDE Approved The paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved Fundamental flaws in the paper seriously undermine the findings and conclusions Version 3 VERSION 3 PUBLISHED 07 Feb 2025 Revised Views 0 Cite How to cite this report: Faouzi J. Reviewer Report For: Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data [version 3; peer review: 2 approved] . F1000Research 2025, 12 :118 ( https://doi.org/10.5256/f1000research.177718.r366375 ) The direct URL for this report is: https://f1000research.com/articles/12-118/v3#referee-response-366375 NOTE: it is important to ensure the information in square brackets after the title is included in this citation. Close Copy Citation Details Reviewer Report 22 Feb 2025 Johann Faouzi , ENSAI, Rennes, France Approved VIEWS 0 https://doi.org/10.5256/f1000research.177718.r366375 I would like to thank the authors for their detailed response. The software development aspects have been ... Continue reading READ ALL I would like to thank the authors for their detailed response. The software development aspects have been substantially improved since the previous version, and I am happy to approve the current version of the article. Competing Interests: No competing interests were disclosed. Reviewer Expertise: Open source software, Python programming, machine learning, medical applications I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard. Close READ LESS CITE CITE HOW TO CITE THIS REPORT Faouzi J. Reviewer Report For: Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data [version 3; peer review: 2 approved] . F1000Research 2025, 12 :118 ( https://doi.org/10.5256/f1000research.177718.r366375 ) The direct URL for this report is: https://f1000research.com/articles/12-118/v3#referee-response-366375 NOTE: it is important to ensure the information in square brackets after the title is included in all citations of this article. COPY CITATION DETAILS Report a concern Respond or Comment COMMENT ON THIS REPORT Version 2 VERSION 2 PUBLISHED 07 May 2024 Revised Views 0 Cite How to cite this report: Sparks R. Reviewer Report For: Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data [version 3; peer review: 2 approved] . F1000Research 2025, 12 :118 ( https://doi.org/10.5256/f1000research.164713.r274815 ) The direct URL for this report is: https://f1000research.com/articles/12-118/v2#referee-response-274815 NOTE: it is important to ensure the information in square brackets after the title is included in this citation. Close Copy Citation Details Reviewer Report 12 Jun 2024 Rachel Sparks , King's College London, London, England, UK Approved VIEWS 0 https://doi.org/10.5256/f1000research.164713.r274815 I am happy with the revisions made to ... Continue reading READ ALL I am happy with the revisions made to the document and responses to my specific queries. Competing Interests: No competing interests were disclosed. Reviewer Expertise: Software development; open source software; medical image computing I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard. Close READ LESS CITE CITE HOW TO CITE THIS REPORT Sparks R. Reviewer Report For: Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data [version 3; peer review: 2 approved] . F1000Research 2025, 12 :118 ( https://doi.org/10.5256/f1000research.164713.r274815 ) The direct URL for this report is: https://f1000research.com/articles/12-118/v2#referee-response-274815 NOTE: it is important to ensure the information in square brackets after the title is included in all citations of this article. COPY CITATION DETAILS Report a concern Respond or Comment COMMENT ON THIS REPORT Views 0 Cite How to cite this report: Faouzi J. Reviewer Report For: Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data [version 3; peer review: 2 approved] . F1000Research 2025, 12 :118 ( https://doi.org/10.5256/f1000research.164713.r274816 ) The direct URL for this report is: https://f1000research.com/articles/12-118/v2#referee-response-274816 NOTE: it is important to ensure the information in square brackets after the title is included in this citation. Close Copy Citation Details Reviewer Report 15 May 2024 Johann Faouzi , ENSAI, Rennes, France Approved with Reservations VIEWS 0 https://doi.org/10.5256/f1000research.164713.r274816 I would like to thank the authors for replying to all my comments. I think that the manuscript has been improved since the first version. Nonetheless, I still have some concerns regarding the source code. Despite some ... Continue reading READ ALL I would like to thank the authors for replying to all my comments. I think that the manuscript has been improved since the first version. Nonetheless, I still have some concerns regarding the source code. Despite some cleaning, there are still numerous flake8 errors. Flake8 is not used in the CI even though it is installed. Code coverage is still not included in the CI. PR with failing CI are still merged into in the main branch. Overall, the software aspect of this contribution, which is the main contribution, has still important limitations. Competing Interests: No competing interests were disclosed. Reviewer Expertise: Open source software, Python programming, machine learning, medical applications I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard, however I have significant reservations, as outlined above. Close READ LESS CITE CITE HOW TO CITE THIS REPORT Faouzi J. Reviewer Report For: Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data [version 3; peer review: 2 approved] . F1000Research 2025, 12 :118 ( https://doi.org/10.5256/f1000research.164713.r274816 ) The direct URL for this report is: https://f1000research.com/articles/12-118/v2#referee-response-274816 NOTE: it is important to ensure the information in square brackets after the title is included in all citations of this article. COPY CITATION DETAILS Report a concern Author Response 14 Jun 2024 Benjamin Haibe-Kains , Princess Margaret Cancer Centre, Canada 14 Jun 2024 Author Response Thank you Dr Faouzi for your feedback regarding our CI/CD pipeline and we are glad to inform you that we have made the appropriate updates. We have switched from ... Continue reading Thank you Dr Faouzi for your feedback regarding our CI/CD pipeline and we are glad to inform you that we have made the appropriate updates. We have switched from flake8 to ruff (Rust-based Python linter) as our main linter and have made appropriate modifications to our codebase to address all linting issues. The linter is also integrated into the CI/CD pipeline as well. The main failure of our previous tests was due to the deprecation of .egg uploads to PyPI, despite the unit tests always passing. We have resolved these issues by rewriting our CI/CD pipeline, which has led to reliable tests and continuous deployments to PyPI. We have also incorporated code coverage into our CI/CD pipeline and have added a badge to the README. While the current code coverage of the tests is still low, we believe after our upcoming refactoring efforts, the coverage of the tests will significantly improve. Finally, we have implemented semantic versioning to our package to adhere to industry standards and ensure consistent, trackable versioning changes. Thank you Dr Faouzi for your feedback regarding our CI/CD pipeline and we are glad to inform you that we have made the appropriate updates. We have switched from flake8 to ruff (Rust-based Python linter) as our main linter and have made appropriate modifications to our codebase to address all linting issues. The linter is also integrated into the CI/CD pipeline as well. The main failure of our previous tests was due to the deprecation of .egg uploads to PyPI, despite the unit tests always passing. We have resolved these issues by rewriting our CI/CD pipeline, which has led to reliable tests and continuous deployments to PyPI. We have also incorporated code coverage into our CI/CD pipeline and have added a badge to the README. While the current code coverage of the tests is still low, we believe after our upcoming refactoring efforts, the coverage of the tests will significantly improve. Finally, we have implemented semantic versioning to our package to adhere to industry standards and ensure consistent, trackable versioning changes. Competing Interests: No competing interests were disclosed. Close Report a concern Respond or Comment COMMENTS ON THIS REPORT Author Response 14 Jun 2024 Benjamin Haibe-Kains , Princess Margaret Cancer Centre, Canada 14 Jun 2024 Author Response Thank you Dr Faouzi for your feedback regarding our CI/CD pipeline and we are glad to inform you that we have made the appropriate updates. We have switched from ... Continue reading Thank you Dr Faouzi for your feedback regarding our CI/CD pipeline and we are glad to inform you that we have made the appropriate updates. We have switched from flake8 to ruff (Rust-based Python linter) as our main linter and have made appropriate modifications to our codebase to address all linting issues. The linter is also integrated into the CI/CD pipeline as well. The main failure of our previous tests was due to the deprecation of .egg uploads to PyPI, despite the unit tests always passing. We have resolved these issues by rewriting our CI/CD pipeline, which has led to reliable tests and continuous deployments to PyPI. We have also incorporated code coverage into our CI/CD pipeline and have added a badge to the README. While the current code coverage of the tests is still low, we believe after our upcoming refactoring efforts, the coverage of the tests will significantly improve. Finally, we have implemented semantic versioning to our package to adhere to industry standards and ensure consistent, trackable versioning changes. Thank you Dr Faouzi for your feedback regarding our CI/CD pipeline and we are glad to inform you that we have made the appropriate updates. We have switched from flake8 to ruff (Rust-based Python linter) as our main linter and have made appropriate modifications to our codebase to address all linting issues. The linter is also integrated into the CI/CD pipeline as well. The main failure of our previous tests was due to the deprecation of .egg uploads to PyPI, despite the unit tests always passing. We have resolved these issues by rewriting our CI/CD pipeline, which has led to reliable tests and continuous deployments to PyPI. We have also incorporated code coverage into our CI/CD pipeline and have added a badge to the README. While the current code coverage of the tests is still low, we believe after our upcoming refactoring efforts, the coverage of the tests will significantly improve. Finally, we have implemented semantic versioning to our package to adhere to industry standards and ensure consistent, trackable versioning changes. Competing Interests: No competing interests were disclosed. Close Report a concern COMMENT ON THIS REPORT Version 1 VERSION 1 PUBLISHED 01 Feb 2023 Views 0 Cite How to cite this report: Faouzi J. Reviewer Report For: Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data [version 3; peer review: 2 approved] . F1000Research 2025, 12 :118 ( https://doi.org/10.5256/f1000research.139617.r189038 ) The direct URL for this report is: https://f1000research.com/articles/12-118/v1#referee-response-189038 NOTE: it is important to ensure the information in square brackets after the title is included in this citation. Close Copy Citation Details Reviewer Report 17 Oct 2023 Johann Faouzi , ENSAI, Rennes, France Approved with Reservations VIEWS 0 https://doi.org/10.5256/f1000research.139617.r189038 The authors present their Python package for data processing pipelines and curating medical imaging data in this manuscript. Overall the manuscript is well written and clearly presents the main contributions of this package to the community. Nonetheless, some points on ... Continue reading READ ALL The authors present their Python package for data processing pipelines and curating medical imaging data in this manuscript. Overall the manuscript is well written and clearly presents the main contributions of this package to the community. Nonetheless, some points on the software side could be improved. Please find my comments below: * How does the output format used compare to other formats such as other popular formats such as BIDS (Brain Imaging Data Structure, which is maybe less general since it's intended for brain imaging data)? * Figure 2b (and the corresponding text): Raw saved running time, even though useful, is irrelevant without knowing the total running time. Please provide also the saved time as a percentage of the total running time. * Figures 2c and 2d: "1 lines" => "1 line" * The authors should consider renaming the "master" branch as the "main" branch (see https://sfconservancy.org/news/2020/jun/23/gitbranchname/). * Is there a reason for Python 3.8 not being tested in the continuous integration (CI) (maybe a limit on the number of jobs)? By the way, Python 3.7 is no longer supported and Python 3.11 has been released for over 9 months (https://devguide.python.org/versions/). The Python versions tested in the CI should probably be updated. * Flake8 is installed in the CI but never used. I ran the command locally (flake8 | wc -l) and obtained 2163 errors or warnings, which is not good. It would be nice to clean the source code a bit. * There is no code coverage associated to the tests, which is an important limitation. Please add code coverage to your project. There are "only" 16 tests for the moment, so I suspect that a substantial part of the source code is not tested. * I don't understand the point of using the "-s" option with pytest. I don't find the output (when using this option) to be clear or useful to identify tests that would fail for instance. In particular, I don't think that printing stuff when running the tests in the CI is relevant. Is the rationale for developing the new software tool clearly explained? Yes Is the description of the software tool technically sound? Yes Are sufficient details of the code, methods and analysis (if applicable) provided to allow replication of the software development and its use by others? Yes Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool? Yes Are the conclusions about the tool and its performance adequately supported by the findings presented in the article? Yes Competing Interests: No competing interests were disclosed. Reviewer Expertise: Open source software, Python programming, machine learning, medical applications I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard, however I have significant reservations, as outlined above. Close READ LESS CITE CITE HOW TO CITE THIS REPORT Faouzi J. Reviewer Report For: Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data [version 3; peer review: 2 approved] . F1000Research 2025, 12 :118 ( https://doi.org/10.5256/f1000research.139617.r189038 ) The direct URL for this report is: https://f1000research.com/articles/12-118/v1#referee-response-189038 NOTE: it is important to ensure the information in square brackets after the title is included in all citations of this article. COPY CITATION DETAILS Report a concern Author Response 07 May 2024 Benjamin Haibe-Kains , Princess Margaret Cancer Centre, Canada 07 May 2024 Author Response We thank Dr Faouzi for his feedback regarding our manuscript titled ‘Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data’. We have added our ... Continue reading We thank Dr Faouzi for his feedback regarding our manuscript titled ‘Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data’. We have added our responses to their comments here in subdivided sections of comments/questions (Q), in bold, our corresponding responses/answers (A), and any relevant sections of the manuscript as an italicized bullet point, with changes emphasized in bold. Q: The authors present their Python package for data processing pipelines and curating medical imaging data in this manuscript. Overall the manuscript is well written and clearly presents the main contributions of this package to the community. Nonetheless, some points on the software side could be improved. Please find my comments below: A: We thank the reviewer for their positive understanding of the authors’ work and constructive feedback, especially on the technical aspects of the package. Q: How does the output format used compare to other formats such as other popular formats such as BIDS (Brain Imaging Data Structure, which is maybe less general since it's intended for brain imaging data)? A: We thank the reviewer for bringing the BIDS standard to the authors’ attention. The BIDS standard is very effective in standardizing brain imaging datasets by adhering to an intuitive structure describing various modalities of brain MRI. Med-ImageTools is mainly geared towards use cases that are broader and less specific than BIDS and its implementation would require fundamental reworkings of the package. However, the benefit of having a BIDS-native output cannot be understated and this feature will be added to the development team’s ongoing development goals. We have revised the relevant section from ‘Current Workflows’ as follows: While Med-ImageTools has many modular functions for image, contour, and dose input/output (IO) built on popular frameworks such as SimpleITK, TorchIO and PyDicom, such functionalities are redundant and available in other open-source packages as well. We have tailored our core features towards broader use cases and development workflows, instead of modality or disease type specific workflows, such as BIDS. Our main contribution is in the development of AutoPipeline and will mainly discuss its functionalities and implementation. Q: Figure 2b (and the corresponding text): Raw saved running time, even though useful, is irrelevant without knowing the total running time. Please provide also the saved time as a percentage of the total running time. A: We appreciate the reviewer’s point about Figure 2b. However, the reported time saved is reported in core-hours, which is a comprehensive unit of total running time. This is because the crawling occurred independently from the end-to-end processing of the datasets to ensure an accurate measure of core-hours saved. Reporting core-hours saved allows the reader to estimate their time/cost savings based on their specific hardware availabilities, either local machine, server-based, or cloud infrastructure, agnOSTIC to the hardware used by the authors. We have emphasIZED this point in our manuscRIPT as fOLLOWS: However, when scaled up to larger TCIA datasets such as OPC-Radiomics 13 (n=606) and NLST 14 (n=26254), it can save researchers 24.7 core-hours and 1072 core-hours, respectively (Figure 2b). The resources saved are reported in core-hours to allow a hardware-agnostic estimation of time and cost savings. While it may vary depending on the research infrastructure utilized, these databases can result in significant savings in billing. Q: Figures 2c and 2d: "1 lines" => "1 line" Q: The authors should consider renaming the "master" branch as the "main" branch (see https://sfconservancy.org/news/2020/jun/23/gitbranchname/). Q: Is there a reason for Python 3.8 not being tested in the continuous integration (CI) (maybe a limit on the number of jobs)? By the way, Python 3.7 is no longer supported and Python 3.11 has been released for over 9 months (https://devguide.python.org/versions/). The Python versions tested in the CI should probably be updated. A: We thank the reviewer for their comments. The figures and repository have been updated to address these points. Q: Flake8 is installed in the CI but never used. I ran the command locally (flake8 | wc -l) and obtained 2163 errors or warnings, which is not good. It would be nice to clean the source code a bit. A: We thank the reviewer for raising the concern about the source code’s sanitation. The authors have reviewed the flake8 output and incorporated it into our codebase. You can find all changes in the following commit: https://github.com/bhklab/med-imagetools/commit/a8c0c3be53b4c9b43da12603b222d261d417a18c . Q: I don't understand the point of using the "-s" option with pytest. I don't find the output (when using this option) to be clear or useful to identify tests that would fail for instance. In particular, I don't think that printing stuff when running the tests in the CI is relevant. A: We thank the reviewer’s attention to detail in Med-ImageTools’ CI/CD framework. The -s option is enabled for verbose outputs from Med-ImageTools to be carried through to the standard output of the tests in CI. In the past we have had OS-specific issues that were elucidated through the -s flag, but have removed it for future releases. Q: There is no code coverage associated to the tests, which is an important limitation. Please add code coverage to your project. There are "only" 16 tests for the moment, so I suspect that a substantial part of the source code is not tested. A: We thank the reviewer for highlighting the lack of code coverage association of these tests. We agree that this is a clear limitation of the Med-ImageTools’ development pipeline, and have significantly increased the number of unit tests and integrated them into our CI/CD process. Future development efforts will continue to add more tests to our pipeline, including a badge detailing code coverage on our README. We thank Dr Faouzi for his feedback regarding our manuscript titled ‘Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data’. We have added our responses to their comments here in subdivided sections of comments/questions (Q), in bold, our corresponding responses/answers (A), and any relevant sections of the manuscript as an italicized bullet point, with changes emphasized in bold. Q: The authors present their Python package for data processing pipelines and curating medical imaging data in this manuscript. Overall the manuscript is well written and clearly presents the main contributions of this package to the community. Nonetheless, some points on the software side could be improved. Please find my comments below: A: We thank the reviewer for their positive understanding of the authors’ work and constructive feedback, especially on the technical aspects of the package. Q: How does the output format used compare to other formats such as other popular formats such as BIDS (Brain Imaging Data Structure, which is maybe less general since it's intended for brain imaging data)? A: We thank the reviewer for bringing the BIDS standard to the authors’ attention. The BIDS standard is very effective in standardizing brain imaging datasets by adhering to an intuitive structure describing various modalities of brain MRI. Med-ImageTools is mainly geared towards use cases that are broader and less specific than BIDS and its implementation would require fundamental reworkings of the package. However, the benefit of having a BIDS-native output cannot be understated and this feature will be added to the development team’s ongoing development goals. We have revised the relevant section from ‘Current Workflows’ as follows: While Med-ImageTools has many modular functions for image, contour, and dose input/output (IO) built on popular frameworks such as SimpleITK, TorchIO and PyDicom, such functionalities are redundant and available in other open-source packages as well. We have tailored our core features towards broader use cases and development workflows, instead of modality or disease type specific workflows, such as BIDS. Our main contribution is in the development of AutoPipeline and will mainly discuss its functionalities and implementation. Q: Figure 2b (and the corresponding text): Raw saved running time, even though useful, is irrelevant without knowing the total running time. Please provide also the saved time as a percentage of the total running time. A: We appreciate the reviewer’s point about Figure 2b. However, the reported time saved is reported in core-hours, which is a comprehensive unit of total running time. This is because the crawling occurred independently from the end-to-end processing of the datasets to ensure an accurate measure of core-hours saved. Reporting core-hours saved allows the reader to estimate their time/cost savings based on their specific hardware availabilities, either local machine, server-based, or cloud infrastructure, agnOSTIC to the hardware used by the authors. We have emphasIZED this point in our manuscRIPT as fOLLOWS: However, when scaled up to larger TCIA datasets such as OPC-Radiomics 13 (n=606) and NLST 14 (n=26254), it can save researchers 24.7 core-hours and 1072 core-hours, respectively (Figure 2b). The resources saved are reported in core-hours to allow a hardware-agnostic estimation of time and cost savings. While it may vary depending on the research infrastructure utilized, these databases can result in significant savings in billing. Q: Figures 2c and 2d: "1 lines" => "1 line" Q: The authors should consider renaming the "master" branch as the "main" branch (see https://sfconservancy.org/news/2020/jun/23/gitbranchname/). Q: Is there a reason for Python 3.8 not being tested in the continuous integration (CI) (maybe a limit on the number of jobs)? By the way, Python 3.7 is no longer supported and Python 3.11 has been released for over 9 months (https://devguide.python.org/versions/). The Python versions tested in the CI should probably be updated. A: We thank the reviewer for their comments. The figures and repository have been updated to address these points. Q: Flake8 is installed in the CI but never used. I ran the command locally (flake8 | wc -l) and obtained 2163 errors or warnings, which is not good. It would be nice to clean the source code a bit. A: We thank the reviewer for raising the concern about the source code’s sanitation. The authors have reviewed the flake8 output and incorporated it into our codebase. You can find all changes in the following commit: https://github.com/bhklab/med-imagetools/commit/a8c0c3be53b4c9b43da12603b222d261d417a18c . Q: I don't understand the point of using the "-s" option with pytest. I don't find the output (when using this option) to be clear or useful to identify tests that would fail for instance. In particular, I don't think that printing stuff when running the tests in the CI is relevant. A: We thank the reviewer’s attention to detail in Med-ImageTools’ CI/CD framework. The -s option is enabled for verbose outputs from Med-ImageTools to be carried through to the standard output of the tests in CI. In the past we have had OS-specific issues that were elucidated through the -s flag, but have removed it for future releases. Q: There is no code coverage associated to the tests, which is an important limitation. Please add code coverage to your project. There are "only" 16 tests for the moment, so I suspect that a substantial part of the source code is not tested. A: We thank the reviewer for highlighting the lack of code coverage association of these tests. We agree that this is a clear limitation of the Med-ImageTools’ development pipeline, and have significantly increased the number of unit tests and integrated them into our CI/CD process. Future development efforts will continue to add more tests to our pipeline, including a badge detailing code coverage on our README. Competing Interests: There are no competing interests to disclose. Close Report a concern Respond or Comment COMMENTS ON THIS REPORT Author Response 07 May 2024 Benjamin Haibe-Kains , Princess Margaret Cancer Centre, Canada 07 May 2024 Author Response We thank Dr Faouzi for his feedback regarding our manuscript titled ‘Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data’. We have added our ... Continue reading We thank Dr Faouzi for his feedback regarding our manuscript titled ‘Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data’. We have added our responses to their comments here in subdivided sections of comments/questions (Q), in bold, our corresponding responses/answers (A), and any relevant sections of the manuscript as an italicized bullet point, with changes emphasized in bold. Q: The authors present their Python package for data processing pipelines and curating medical imaging data in this manuscript. Overall the manuscript is well written and clearly presents the main contributions of this package to the community. Nonetheless, some points on the software side could be improved. Please find my comments below: A: We thank the reviewer for their positive understanding of the authors’ work and constructive feedback, especially on the technical aspects of the package. Q: How does the output format used compare to other formats such as other popular formats such as BIDS (Brain Imaging Data Structure, which is maybe less general since it's intended for brain imaging data)? A: We thank the reviewer for bringing the BIDS standard to the authors’ attention. The BIDS standard is very effective in standardizing brain imaging datasets by adhering to an intuitive structure describing various modalities of brain MRI. Med-ImageTools is mainly geared towards use cases that are broader and less specific than BIDS and its implementation would require fundamental reworkings of the package. However, the benefit of having a BIDS-native output cannot be understated and this feature will be added to the development team’s ongoing development goals. We have revised the relevant section from ‘Current Workflows’ as follows: While Med-ImageTools has many modular functions for image, contour, and dose input/output (IO) built on popular frameworks such as SimpleITK, TorchIO and PyDicom, such functionalities are redundant and available in other open-source packages as well. We have tailored our core features towards broader use cases and development workflows, instead of modality or disease type specific workflows, such as BIDS. Our main contribution is in the development of AutoPipeline and will mainly discuss its functionalities and implementation. Q: Figure 2b (and the corresponding text): Raw saved running time, even though useful, is irrelevant without knowing the total running time. Please provide also the saved time as a percentage of the total running time. A: We appreciate the reviewer’s point about Figure 2b. However, the reported time saved is reported in core-hours, which is a comprehensive unit of total running time. This is because the crawling occurred independently from the end-to-end processing of the datasets to ensure an accurate measure of core-hours saved. Reporting core-hours saved allows the reader to estimate their time/cost savings based on their specific hardware availabilities, either local machine, server-based, or cloud infrastructure, agnOSTIC to the hardware used by the authors. We have emphasIZED this point in our manuscRIPT as fOLLOWS: However, when scaled up to larger TCIA datasets such as OPC-Radiomics 13 (n=606) and NLST 14 (n=26254), it can save researchers 24.7 core-hours and 1072 core-hours, respectively (Figure 2b). The resources saved are reported in core-hours to allow a hardware-agnostic estimation of time and cost savings. While it may vary depending on the research infrastructure utilized, these databases can result in significant savings in billing. Q: Figures 2c and 2d: "1 lines" => "1 line" Q: The authors should consider renaming the "master" branch as the "main" branch (see https://sfconservancy.org/news/2020/jun/23/gitbranchname/). Q: Is there a reason for Python 3.8 not being tested in the continuous integration (CI) (maybe a limit on the number of jobs)? By the way, Python 3.7 is no longer supported and Python 3.11 has been released for over 9 months (https://devguide.python.org/versions/). The Python versions tested in the CI should probably be updated. A: We thank the reviewer for their comments. The figures and repository have been updated to address these points. Q: Flake8 is installed in the CI but never used. I ran the command locally (flake8 | wc -l) and obtained 2163 errors or warnings, which is not good. It would be nice to clean the source code a bit. A: We thank the reviewer for raising the concern about the source code’s sanitation. The authors have reviewed the flake8 output and incorporated it into our codebase. You can find all changes in the following commit: https://github.com/bhklab/med-imagetools/commit/a8c0c3be53b4c9b43da12603b222d261d417a18c . Q: I don't understand the point of using the "-s" option with pytest. I don't find the output (when using this option) to be clear or useful to identify tests that would fail for instance. In particular, I don't think that printing stuff when running the tests in the CI is relevant. A: We thank the reviewer’s attention to detail in Med-ImageTools’ CI/CD framework. The -s option is enabled for verbose outputs from Med-ImageTools to be carried through to the standard output of the tests in CI. In the past we have had OS-specific issues that were elucidated through the -s flag, but have removed it for future releases. Q: There is no code coverage associated to the tests, which is an important limitation. Please add code coverage to your project. There are "only" 16 tests for the moment, so I suspect that a substantial part of the source code is not tested. A: We thank the reviewer for highlighting the lack of code coverage association of these tests. We agree that this is a clear limitation of the Med-ImageTools’ development pipeline, and have significantly increased the number of unit tests and integrated them into our CI/CD process. Future development efforts will continue to add more tests to our pipeline, including a badge detailing code coverage on our README. We thank Dr Faouzi for his feedback regarding our manuscript titled ‘Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data’. We have added our responses to their comments here in subdivided sections of comments/questions (Q), in bold, our corresponding responses/answers (A), and any relevant sections of the manuscript as an italicized bullet point, with changes emphasized in bold. Q: The authors present their Python package for data processing pipelines and curating medical imaging data in this manuscript. Overall the manuscript is well written and clearly presents the main contributions of this package to the community. Nonetheless, some points on the software side could be improved. Please find my comments below: A: We thank the reviewer for their positive understanding of the authors’ work and constructive feedback, especially on the technical aspects of the package. Q: How does the output format used compare to other formats such as other popular formats such as BIDS (Brain Imaging Data Structure, which is maybe less general since it's intended for brain imaging data)? A: We thank the reviewer for bringing the BIDS standard to the authors’ attention. The BIDS standard is very effective in standardizing brain imaging datasets by adhering to an intuitive structure describing various modalities of brain MRI. Med-ImageTools is mainly geared towards use cases that are broader and less specific than BIDS and its implementation would require fundamental reworkings of the package. However, the benefit of having a BIDS-native output cannot be understated and this feature will be added to the development team’s ongoing development goals. We have revised the relevant section from ‘Current Workflows’ as follows: While Med-ImageTools has many modular functions for image, contour, and dose input/output (IO) built on popular frameworks such as SimpleITK, TorchIO and PyDicom, such functionalities are redundant and available in other open-source packages as well. We have tailored our core features towards broader use cases and development workflows, instead of modality or disease type specific workflows, such as BIDS. Our main contribution is in the development of AutoPipeline and will mainly discuss its functionalities and implementation. Q: Figure 2b (and the corresponding text): Raw saved running time, even though useful, is irrelevant without knowing the total running time. Please provide also the saved time as a percentage of the total running time. A: We appreciate the reviewer’s point about Figure 2b. However, the reported time saved is reported in core-hours, which is a comprehensive unit of total running time. This is because the crawling occurred independently from the end-to-end processing of the datasets to ensure an accurate measure of core-hours saved. Reporting core-hours saved allows the reader to estimate their time/cost savings based on their specific hardware availabilities, either local machine, server-based, or cloud infrastructure, agnOSTIC to the hardware used by the authors. We have emphasIZED this point in our manuscRIPT as fOLLOWS: However, when scaled up to larger TCIA datasets such as OPC-Radiomics 13 (n=606) and NLST 14 (n=26254), it can save researchers 24.7 core-hours and 1072 core-hours, respectively (Figure 2b). The resources saved are reported in core-hours to allow a hardware-agnostic estimation of time and cost savings. While it may vary depending on the research infrastructure utilized, these databases can result in significant savings in billing. Q: Figures 2c and 2d: "1 lines" => "1 line" Q: The authors should consider renaming the "master" branch as the "main" branch (see https://sfconservancy.org/news/2020/jun/23/gitbranchname/). Q: Is there a reason for Python 3.8 not being tested in the continuous integration (CI) (maybe a limit on the number of jobs)? By the way, Python 3.7 is no longer supported and Python 3.11 has been released for over 9 months (https://devguide.python.org/versions/). The Python versions tested in the CI should probably be updated. A: We thank the reviewer for their comments. The figures and repository have been updated to address these points. Q: Flake8 is installed in the CI but never used. I ran the command locally (flake8 | wc -l) and obtained 2163 errors or warnings, which is not good. It would be nice to clean the source code a bit. A: We thank the reviewer for raising the concern about the source code’s sanitation. The authors have reviewed the flake8 output and incorporated it into our codebase. You can find all changes in the following commit: https://github.com/bhklab/med-imagetools/commit/a8c0c3be53b4c9b43da12603b222d261d417a18c . Q: I don't understand the point of using the "-s" option with pytest. I don't find the output (when using this option) to be clear or useful to identify tests that would fail for instance. In particular, I don't think that printing stuff when running the tests in the CI is relevant. A: We thank the reviewer’s attention to detail in Med-ImageTools’ CI/CD framework. The -s option is enabled for verbose outputs from Med-ImageTools to be carried through to the standard output of the tests in CI. In the past we have had OS-specific issues that were elucidated through the -s flag, but have removed it for future releases. Q: There is no code coverage associated to the tests, which is an important limitation. Please add code coverage to your project. There are "only" 16 tests for the moment, so I suspect that a substantial part of the source code is not tested. A: We thank the reviewer for highlighting the lack of code coverage association of these tests. We agree that this is a clear limitation of the Med-ImageTools’ development pipeline, and have significantly increased the number of unit tests and integrated them into our CI/CD process. Future development efforts will continue to add more tests to our pipeline, including a badge detailing code coverage on our README. Competing Interests: There are no competing interests to disclose. Close Report a concern COMMENT ON THIS REPORT Views 0 Cite How to cite this report: Sparks R. Reviewer Report For: Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data [version 3; peer review: 2 approved] . F1000Research 2025, 12 :118 ( https://doi.org/10.5256/f1000research.139617.r189015 ) The direct URL for this report is: https://f1000research.com/articles/12-118/v1#referee-response-189015 NOTE: it is important to ensure the information in square brackets after the title is included in this citation. Close Copy Citation Details Reviewer Report 17 Oct 2023 Rachel Sparks , King's College London, London, England, UK Approved with Reservations VIEWS 0 https://doi.org/10.5256/f1000research.139617.r189015 I think the motivation and justification for why a light weight Python module to support data loading and preprocessing of radiotherapy DICOM formats was very well articulated and clear. And I applaud the authors on making such a useful tool ... Continue reading READ ALL I think the motivation and justification for why a light weight Python module to support data loading and preprocessing of radiotherapy DICOM formats was very well articulated and clear. And I applaud the authors on making such a useful tool available to the community. However, I have two major concerns that must be addressed prior to this article being acceptable for indexing. First there are no details as to the design of Med-Image-Tools this includes important information such as: (1) dependencies on other python packages (2) what functions or other tools are being leveraged within the tool and how these are arranged. (3) the structure of the outputs of this pipeline specifically the csv file corresponding to the 'Dataset Index', the imaging and non-imaging feature outputs. For instance for imaging data how are pre-operative scans and segmentations saved and named (is there a convention is this something the user must write) (4) While there is a reference to the tutorial about the processing pipeline I think a high level overview listing the possible options would be appropriate to help the reader understand what this tool can offer. My other concern is related to the use cases. While lines of code is an easy metric to report it is mostly meaningless, some lines of code may be boilerplate or easy to write while others may obviously be different. It is also easy to pad or alter depending on the level of skill of the programmer. I think reporting run time is far more meaningful to your argument and I would stick to these. Finally, specifically, for the RADCURE dataset, it is not clear to me why you are comparing run time on a single core versus run time on a 32 core machine. I suspect the reported run time for the comparison could be significantly reduced by using a very simple parallelization which should be achievable tools available in python. I would suggest a fairer comparison for this specific example, it wont detract from the best argument you have which is there you are presenting a nice package so that other developers and researchers do not have to spend time re-writing code. Highlighting where some time savings may be gained is in some ways a secondary advantage. Finally, as a minor note the statement that SlicerRT is not easily interfaced with python is not a fully justified statement. One can use the python interface in Slicer to run python scripts and even run from the command prompt by called s'licer.exe --python-code'. However, I think you can modify this to make a true and equally motivated statement which is that SlicerRT requires one to install Slicer/SlicerRT and stay within the slicer ecosystem to process data. Your tool lacks such dependencies so can be a more light weight and does not require running python through another software system. Is the rationale for developing the new software tool clearly explained? Yes Is the description of the software tool technically sound? No Are sufficient details of the code, methods and analysis (if applicable) provided to allow replication of the software development and its use by others? No Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool? No Are the conclusions about the tool and its performance adequately supported by the findings presented in the article? Yes Competing Interests: No competing interests were disclosed. Reviewer Expertise: Software development; open source software; medical image computing I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard, however I have significant reservations, as outlined above. Close READ LESS CITE CITE HOW TO CITE THIS REPORT Sparks R. Reviewer Report For: Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data [version 3; peer review: 2 approved] . F1000Research 2025, 12 :118 ( https://doi.org/10.5256/f1000research.139617.r189015 ) The direct URL for this report is: https://f1000research.com/articles/12-118/v1#referee-response-189015 NOTE: it is important to ensure the information in square brackets after the title is included in all citations of this article. COPY CITATION DETAILS Report a concern Author Response 07 May 2024 Benjamin Haibe-Kains , Princess Margaret Cancer Centre, Canada 07 May 2024 Author Response We thank Dr Sparks for her feedback regarding our manuscript titled ‘Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data’. We have added our ... Continue reading We thank Dr Sparks for her feedback regarding our manuscript titled ‘Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data’. We have added our responses to their comments here in subdivided sections of comments/questions (Q), in bold, our corresponding responses/answers (A), and any relevant sections of the manuscript as an italicized bullet point, with changes emphasized in bold. Q: I think the motivation and justification for why a light weight Python module to support data loading and preprocessing of radiotherapy DICOM formats was very well articulated and clear. And I applaud the authors on making such a useful tool available to the community. A: We thank the reviewer for their recognition of Med-ImageTools’ contribution to the medical imaging community and positively evaluating the authors’ works. Q: However, I have two major concerns that must be addressed prior to this article being acceptable for indexing. First there are no details as to the design of Med-Image-Tools this includes important information such as: (1) dependencies on other python packages A: We thank the reviewer for pointing out the need to communicate the technical dependencies of Med-ImageTools. We have updated our ‘AutoPipeline’ section as follows, to include information on how to find the list of package dependencies. Running the ‘ pip install med-imagetools’ command will install the latest version of Med-ImageTools and its associated dependencies defined by the requirements.txt file. The ‘Current workflows’ section also contains a concise description of what frameworks Med-ImageTools leverages such as follows: While Med-ImageTools has many modular functions for image, contour, and dose input/output (IO) built on popular frameworks such as SimpleITK, TorchIO and PyDicom… Q: (2) what functions or other tools are being leveraged within the tool and how these are arranged. A: We thank the reviewer for calling attention to the need to clarify how other tools/packages function within Med-ImageTools. We have added some information to our ‘AutoPipeline’ section to clarify major operations performed using external tools/packages as follows. For a granular understanding of the integration behind every external tool, we defer the reader to learn about the design choices made throughout the package and its implications by gaining a deeper understanding of the source code available through our GitHub repository. 1. Crawl: The crawler opens every DICOM file in the dataset using Pydicom, indexing important metadata, such as unique identifiers, modality information, and references to other modalities. This produces a database of every unique image and DICOM-RT modality. 3. Process: All identified samples are processed according to imaging and transformation parameters defined by the user. The user can configure parameters such as the pixel spacing in mm(s), which specific modalities to process, the number of cores they want to use for multiprocessing, and define nnU-Net specific flags as well. The images are manipulated using SimpleITK without requiring user intervention. As the crawl and process steps are computationally intensive, all steps in AutoPipeline are automatically parallelized using the joblib backend to efficiently leverage all available computational resources. Q: (3) the structure of the outputs of this pipeline specifically the csv file corresponding to the 'Dataset Index', the imaging and non-imaging feature outputs. For instance for imaging data how are pre-operative scans and segmentations saved and named (is there a convention is this something the user must write) A: We thank the reviewer for this question and for highlighting the lack of clarity of our description of AutoPipeline. The ‘Dataset Index’ is designed to be an autogenerated output of the Crawler and does not require any user interaction to be created; this is simply there to ensure convenient user experience. We have made this and other aspects of the outputs clearer by adding the following sentences to the ‘AutoPipeline’ section. Med-ImageTools also generates files that are not analysis-ready images, such as the autogenerated ‘Dataset Index’ (Figure 1), and stores them in a folder named “.imgtools” at the path of the ‘input_directory’. This is to ensure a convenient user experience and intuitive folder structure by hiding extraneous components. Q: (4) While there is a reference to the tutorial about the processing pipeline I think a high level overview listing the possible options would be appropriate to help the reader understand what this tool can offer. A: We agree with the reviewer that adding this information to our description of AutoPipeline can help readers quickly understand the tool’s strengths before interfacing with the GitHub repository or ReadTheDocs. We have updated the ‘AutoPipeline’ section accordingly. 3. Process: All identified samples are processed according to imaging and transformation parameters defined by the user. The user can configure parameters such as: the pixel spacing in mm(s), which specific modalities to process, the number of cores they want to use for multiprocessing, and define nnU-Net specific flags as well. The images are manipulated using SimpleITK without requiring user intervention. Q: My other concern is related to the use cases. While lines of code is an easy metric to report it is mostly meaningless, some lines of code may be boilerplate or easy to write while others may obviously be different. It is also easy to pad or alter depending on the level of skill of the programmer. I think reporting run time is far more meaningful to your argument and I would stick to these. A: We appreciate the reviewer’s consideration in the metrics reported in Figure 2. However, we believe this metric emphasizes Med-ImageTools’ strength allowing users to process DICOM datasets with a single command line interaction, in contrast to writing dozens of lines of Python/R/MATLAB scripts. One particular reason why we believe a single command line is useful to highlight is to express the ease-of-use for users that may not be comfortable writing their own code for DICOM to NifTI/Nrrd processing, especially if they lack deep domain knowledge. Another, perhaps more, exciting reason is to show the potential of building automated workflows on top of Med-ImageTools. If one were to build an end-to-end automated pipeline starting from clinical DICOM datasets to outputting an inference-ready deep learning model, they could easily develop a reproducible processing step by configuring only the command line interaction of Med-ImageTools, making debugging and custom configurations simpler since the developer would not have to rely on a static script. We have elaborated on Med-ImageTools’ contributions for improved scientific reproducibility in the ‘Discussion’ section as follows. The AutoPipeline feature will improve the accessibility of raw clinical datasets on public archives, such as TCIA, allowing machine learning researchers to process analysis-ready formats without requiring deep domain knowledge. Another exciting potential of Med-ImageTools lies in building automated workflows using AutoPipeline. For a researcher to build an end-to-end automated pipeline starting from clinical DICOM datasets to outputting an inference-ready deep learning model, they could easily develop a reproducible processing step by configuring only the command line interaction of Med-ImageTools, making debugging and custom configurations simpler since the developer would not have to rely on a static script. No single solution can completely solve the reproducibility crisis of medical deep learning research, due to a variety of issues ranging from ambiguous data processing techniques to stochasticity of model training. However, community-centered open-source solutions and increased clinical adherence to data standards, such as contour nomenclature, 15 can incrementally improve research quality and reproducibility, and make medical deep learning research more accessible for everyone. Q: Finally, specifically, for the RADCURE dataset, it is not clear to me why you are comparing run time on a single core versus run time on a 32 core machine. I suspect the reported run time for the comparison could be significantly reduced by using a very simple parallelization which should be achievable tools available in python. I would suggest a fairer comparison for this specific example, it wont detract from the best argument you have which is there you are presenting a nice package so that other developers and researchers do not have to spend time re-writing code. Highlighting where some time savings may be gained is in some ways a secondary advantage. A: We thank the reviewer for their comment about Figure 2d. The goal of the comparison was not only to show a reduction in processing time based on parallelization, but to show that our package’s design does not bottleneck any multiprocessing backends and brings meaningful acceleration on large datasets. In other words, we wanted to show that a 32x increase in computational hardware was going to bring at least 32x improvement in performance as observed in Figure 2d. This is in contrast to Figure 2c which does not show similar levels hardware acceleration, but its usefulness in parsing private, unseen data. We have expanded on these ideas in the manuscript as follows: In contrast, on the same 6-core machine (16GB RAM, Windows 10), AutoPipeline took only 2.3 hours with 1 command line, mainly accelerated by parallelization ( Figure 2c). The authors involved in validating Med-ImageTools' effectiveness on this private dataset had no active involvement in the development of the package before its application. This highlights the package’s robustness on unseen data and its potential utility for multi-centre collaborations to ensure consistent processing. One use case might be to enable federated learning platforms to automatically process each node’s datasets without requiring any user intervention. AutoPipeline scales dramatically based on the number of cores available, which enables the entire dataset to be processed in 40 minutes using 32 cores, automatically managing the directories from different systems and extracting the contours ( Figure 2d). These results demonstrate Med-ImageTools' design does not bottleneck any multiprocessing backends and brings meaningful acceleration on very large datasets, such as RADCURE. Q: Finally, as a minor note the statement that SlicerRT is not easily interfaced with python is not a fully justified statement. One can use the python interface in Slicer to run python scripts and even run from the command prompt by called s'licer.exe --python-code'. However, I think you can modify this to make a true and equally motivated statement which is that SlicerRT requires one to install Slicer/SlicerRT and stay within the slicer ecosystem to process data. Your tool lacks such dependencies so can be a more light weight and does not require running python through another software system. A: We thank the reviewer for this point. We have revised the relevant section from ‘Current Workflows’ as follows to better justify our statement. Despite its broad adoption, batch data processing with Slicer requires custom scripting in Python, to be executed in the Slicer ecosystem. Rather than simply installing a package within their Python environment, users must install the Slicer application and add any other dependencies, not provided by Slicer, into the application environment. As a result, machine learning projects relying on Python for data preprocessing will have their code fragmented across multiple environments–the Slicer environment for data processing, and another Python environment for data analysis and machine learning. We thank Dr Sparks for her feedback regarding our manuscript titled ‘Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data’. We have added our responses to their comments here in subdivided sections of comments/questions (Q), in bold, our corresponding responses/answers (A), and any relevant sections of the manuscript as an italicized bullet point, with changes emphasized in bold. Q: I think the motivation and justification for why a light weight Python module to support data loading and preprocessing of radiotherapy DICOM formats was very well articulated and clear. And I applaud the authors on making such a useful tool available to the community. A: We thank the reviewer for their recognition of Med-ImageTools’ contribution to the medical imaging community and positively evaluating the authors’ works. Q: However, I have two major concerns that must be addressed prior to this article being acceptable for indexing. First there are no details as to the design of Med-Image-Tools this includes important information such as: (1) dependencies on other python packages A: We thank the reviewer for pointing out the need to communicate the technical dependencies of Med-ImageTools. We have updated our ‘AutoPipeline’ section as follows, to include information on how to find the list of package dependencies. Running the ‘ pip install med-imagetools’ command will install the latest version of Med-ImageTools and its associated dependencies defined by the requirements.txt file. The ‘Current workflows’ section also contains a concise description of what frameworks Med-ImageTools leverages such as follows: While Med-ImageTools has many modular functions for image, contour, and dose input/output (IO) built on popular frameworks such as SimpleITK, TorchIO and PyDicom… Q: (2) what functions or other tools are being leveraged within the tool and how these are arranged. A: We thank the reviewer for calling attention to the need to clarify how other tools/packages function within Med-ImageTools. We have added some information to our ‘AutoPipeline’ section to clarify major operations performed using external tools/packages as follows. For a granular understanding of the integration behind every external tool, we defer the reader to learn about the design choices made throughout the package and its implications by gaining a deeper understanding of the source code available through our GitHub repository. 1. Crawl: The crawler opens every DICOM file in the dataset using Pydicom, indexing important metadata, such as unique identifiers, modality information, and references to other modalities. This produces a database of every unique image and DICOM-RT modality. 3. Process: All identified samples are processed according to imaging and transformation parameters defined by the user. The user can configure parameters such as the pixel spacing in mm(s), which specific modalities to process, the number of cores they want to use for multiprocessing, and define nnU-Net specific flags as well. The images are manipulated using SimpleITK without requiring user intervention. As the crawl and process steps are computationally intensive, all steps in AutoPipeline are automatically parallelized using the joblib backend to efficiently leverage all available computational resources. Q: (3) the structure of the outputs of this pipeline specifically the csv file corresponding to the 'Dataset Index', the imaging and non-imaging feature outputs. For instance for imaging data how are pre-operative scans and segmentations saved and named (is there a convention is this something the user must write) A: We thank the reviewer for this question and for highlighting the lack of clarity of our description of AutoPipeline. The ‘Dataset Index’ is designed to be an autogenerated output of the Crawler and does not require any user interaction to be created; this is simply there to ensure convenient user experience. We have made this and other aspects of the outputs clearer by adding the following sentences to the ‘AutoPipeline’ section. Med-ImageTools also generates files that are not analysis-ready images, such as the autogenerated ‘Dataset Index’ (Figure 1), and stores them in a folder named “.imgtools” at the path of the ‘input_directory’. This is to ensure a convenient user experience and intuitive folder structure by hiding extraneous components. Q: (4) While there is a reference to the tutorial about the processing pipeline I think a high level overview listing the possible options would be appropriate to help the reader understand what this tool can offer. A: We agree with the reviewer that adding this information to our description of AutoPipeline can help readers quickly understand the tool’s strengths before interfacing with the GitHub repository or ReadTheDocs. We have updated the ‘AutoPipeline’ section accordingly. 3. Process: All identified samples are processed according to imaging and transformation parameters defined by the user. The user can configure parameters such as: the pixel spacing in mm(s), which specific modalities to process, the number of cores they want to use for multiprocessing, and define nnU-Net specific flags as well. The images are manipulated using SimpleITK without requiring user intervention. Q: My other concern is related to the use cases. While lines of code is an easy metric to report it is mostly meaningless, some lines of code may be boilerplate or easy to write while others may obviously be different. It is also easy to pad or alter depending on the level of skill of the programmer. I think reporting run time is far more meaningful to your argument and I would stick to these. A: We appreciate the reviewer’s consideration in the metrics reported in Figure 2. However, we believe this metric emphasizes Med-ImageTools’ strength allowing users to process DICOM datasets with a single command line interaction, in contrast to writing dozens of lines of Python/R/MATLAB scripts. One particular reason why we believe a single command line is useful to highlight is to express the ease-of-use for users that may not be comfortable writing their own code for DICOM to NifTI/Nrrd processing, especially if they lack deep domain knowledge. Another, perhaps more, exciting reason is to show the potential of building automated workflows on top of Med-ImageTools. If one were to build an end-to-end automated pipeline starting from clinical DICOM datasets to outputting an inference-ready deep learning model, they could easily develop a reproducible processing step by configuring only the command line interaction of Med-ImageTools, making debugging and custom configurations simpler since the developer would not have to rely on a static script. We have elaborated on Med-ImageTools’ contributions for improved scientific reproducibility in the ‘Discussion’ section as follows. The AutoPipeline feature will improve the accessibility of raw clinical datasets on public archives, such as TCIA, allowing machine learning researchers to process analysis-ready formats without requiring deep domain knowledge. Another exciting potential of Med-ImageTools lies in building automated workflows using AutoPipeline. For a researcher to build an end-to-end automated pipeline starting from clinical DICOM datasets to outputting an inference-ready deep learning model, they could easily develop a reproducible processing step by configuring only the command line interaction of Med-ImageTools, making debugging and custom configurations simpler since the developer would not have to rely on a static script. No single solution can completely solve the reproducibility crisis of medical deep learning research, due to a variety of issues ranging from ambiguous data processing techniques to stochasticity of model training. However, community-centered open-source solutions and increased clinical adherence to data standards, such as contour nomenclature, 15 can incrementally improve research quality and reproducibility, and make medical deep learning research more accessible for everyone. Q: Finally, specifically, for the RADCURE dataset, it is not clear to me why you are comparing run time on a single core versus run time on a 32 core machine. I suspect the reported run time for the comparison could be significantly reduced by using a very simple parallelization which should be achievable tools available in python. I would suggest a fairer comparison for this specific example, it wont detract from the best argument you have which is there you are presenting a nice package so that other developers and researchers do not have to spend time re-writing code. Highlighting where some time savings may be gained is in some ways a secondary advantage. A: We thank the reviewer for their comment about Figure 2d. The goal of the comparison was not only to show a reduction in processing time based on parallelization, but to show that our package’s design does not bottleneck any multiprocessing backends and brings meaningful acceleration on large datasets. In other words, we wanted to show that a 32x increase in computational hardware was going to bring at least 32x improvement in performance as observed in Figure 2d. This is in contrast to Figure 2c which does not show similar levels hardware acceleration, but its usefulness in parsing private, unseen data. We have expanded on these ideas in the manuscript as follows: In contrast, on the same 6-core machine (16GB RAM, Windows 10), AutoPipeline took only 2.3 hours with 1 command line, mainly accelerated by parallelization ( Figure 2c). The authors involved in validating Med-ImageTools' effectiveness on this private dataset had no active involvement in the development of the package before its application. This highlights the package’s robustness on unseen data and its potential utility for multi-centre collaborations to ensure consistent processing. One use case might be to enable federated learning platforms to automatically process each node’s datasets without requiring any user intervention. AutoPipeline scales dramatically based on the number of cores available, which enables the entire dataset to be processed in 40 minutes using 32 cores, automatically managing the directories from different systems and extracting the contours ( Figure 2d). These results demonstrate Med-ImageTools' design does not bottleneck any multiprocessing backends and brings meaningful acceleration on very large datasets, such as RADCURE. Q: Finally, as a minor note the statement that SlicerRT is not easily interfaced with python is not a fully justified statement. One can use the python interface in Slicer to run python scripts and even run from the command prompt by called s'licer.exe --python-code'. However, I think you can modify this to make a true and equally motivated statement which is that SlicerRT requires one to install Slicer/SlicerRT and stay within the slicer ecosystem to process data. Your tool lacks such dependencies so can be a more light weight and does not require running python through another software system. A: We thank the reviewer for this point. We have revised the relevant section from ‘Current Workflows’ as follows to better justify our statement. Despite its broad adoption, batch data processing with Slicer requires custom scripting in Python, to be executed in the Slicer ecosystem. Rather than simply installing a package within their Python environment, users must install the Slicer application and add any other dependencies, not provided by Slicer, into the application environment. As a result, machine learning projects relying on Python for data preprocessing will have their code fragmented across multiple environments–the Slicer environment for data processing, and another Python environment for data analysis and machine learning. Competing Interests: There are no competing interests to disclose. Close Report a concern Respond or Comment COMMENTS ON THIS REPORT Author Response 07 May 2024 Benjamin Haibe-Kains , Princess Margaret Cancer Centre, Canada 07 May 2024 Author Response We thank Dr Sparks for her feedback regarding our manuscript titled ‘Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data’. We have added our ... Continue reading We thank Dr Sparks for her feedback regarding our manuscript titled ‘Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data’. We have added our responses to their comments here in subdivided sections of comments/questions (Q), in bold, our corresponding responses/answers (A), and any relevant sections of the manuscript as an italicized bullet point, with changes emphasized in bold. Q: I think the motivation and justification for why a light weight Python module to support data loading and preprocessing of radiotherapy DICOM formats was very well articulated and clear. And I applaud the authors on making such a useful tool available to the community. A: We thank the reviewer for their recognition of Med-ImageTools’ contribution to the medical imaging community and positively evaluating the authors’ works. Q: However, I have two major concerns that must be addressed prior to this article being acceptable for indexing. First there are no details as to the design of Med-Image-Tools this includes important information such as: (1) dependencies on other python packages A: We thank the reviewer for pointing out the need to communicate the technical dependencies of Med-ImageTools. We have updated our ‘AutoPipeline’ section as follows, to include information on how to find the list of package dependencies. Running the ‘ pip install med-imagetools’ command will install the latest version of Med-ImageTools and its associated dependencies defined by the requirements.txt file. The ‘Current workflows’ section also contains a concise description of what frameworks Med-ImageTools leverages such as follows: While Med-ImageTools has many modular functions for image, contour, and dose input/output (IO) built on popular frameworks such as SimpleITK, TorchIO and PyDicom… Q: (2) what functions or other tools are being leveraged within the tool and how these are arranged. A: We thank the reviewer for calling attention to the need to clarify how other tools/packages function within Med-ImageTools. We have added some information to our ‘AutoPipeline’ section to clarify major operations performed using external tools/packages as follows. For a granular understanding of the integration behind every external tool, we defer the reader to learn about the design choices made throughout the package and its implications by gaining a deeper understanding of the source code available through our GitHub repository. 1. Crawl: The crawler opens every DICOM file in the dataset using Pydicom, indexing important metadata, such as unique identifiers, modality information, and references to other modalities. This produces a database of every unique image and DICOM-RT modality. 3. Process: All identified samples are processed according to imaging and transformation parameters defined by the user. The user can configure parameters such as the pixel spacing in mm(s), which specific modalities to process, the number of cores they want to use for multiprocessing, and define nnU-Net specific flags as well. The images are manipulated using SimpleITK without requiring user intervention. As the crawl and process steps are computationally intensive, all steps in AutoPipeline are automatically parallelized using the joblib backend to efficiently leverage all available computational resources. Q: (3) the structure of the outputs of this pipeline specifically the csv file corresponding to the 'Dataset Index', the imaging and non-imaging feature outputs. For instance for imaging data how are pre-operative scans and segmentations saved and named (is there a convention is this something the user must write) A: We thank the reviewer for this question and for highlighting the lack of clarity of our description of AutoPipeline. The ‘Dataset Index’ is designed to be an autogenerated output of the Crawler and does not require any user interaction to be created; this is simply there to ensure convenient user experience. We have made this and other aspects of the outputs clearer by adding the following sentences to the ‘AutoPipeline’ section. Med-ImageTools also generates files that are not analysis-ready images, such as the autogenerated ‘Dataset Index’ (Figure 1), and stores them in a folder named “.imgtools” at the path of the ‘input_directory’. This is to ensure a convenient user experience and intuitive folder structure by hiding extraneous components. Q: (4) While there is a reference to the tutorial about the processing pipeline I think a high level overview listing the possible options would be appropriate to help the reader understand what this tool can offer. A: We agree with the reviewer that adding this information to our description of AutoPipeline can help readers quickly understand the tool’s strengths before interfacing with the GitHub repository or ReadTheDocs. We have updated the ‘AutoPipeline’ section accordingly. 3. Process: All identified samples are processed according to imaging and transformation parameters defined by the user. The user can configure parameters such as: the pixel spacing in mm(s), which specific modalities to process, the number of cores they want to use for multiprocessing, and define nnU-Net specific flags as well. The images are manipulated using SimpleITK without requiring user intervention. Q: My other concern is related to the use cases. While lines of code is an easy metric to report it is mostly meaningless, some lines of code may be boilerplate or easy to write while others may obviously be different. It is also easy to pad or alter depending on the level of skill of the programmer. I think reporting run time is far more meaningful to your argument and I would stick to these. A: We appreciate the reviewer’s consideration in the metrics reported in Figure 2. However, we believe this metric emphasizes Med-ImageTools’ strength allowing users to process DICOM datasets with a single command line interaction, in contrast to writing dozens of lines of Python/R/MATLAB scripts. One particular reason why we believe a single command line is useful to highlight is to express the ease-of-use for users that may not be comfortable writing their own code for DICOM to NifTI/Nrrd processing, especially if they lack deep domain knowledge. Another, perhaps more, exciting reason is to show the potential of building automated workflows on top of Med-ImageTools. If one were to build an end-to-end automated pipeline starting from clinical DICOM datasets to outputting an inference-ready deep learning model, they could easily develop a reproducible processing step by configuring only the command line interaction of Med-ImageTools, making debugging and custom configurations simpler since the developer would not have to rely on a static script. We have elaborated on Med-ImageTools’ contributions for improved scientific reproducibility in the ‘Discussion’ section as follows. The AutoPipeline feature will improve the accessibility of raw clinical datasets on public archives, such as TCIA, allowing machine learning researchers to process analysis-ready formats without requiring deep domain knowledge. Another exciting potential of Med-ImageTools lies in building automated workflows using AutoPipeline. For a researcher to build an end-to-end automated pipeline starting from clinical DICOM datasets to outputting an inference-ready deep learning model, they could easily develop a reproducible processing step by configuring only the command line interaction of Med-ImageTools, making debugging and custom configurations simpler since the developer would not have to rely on a static script. No single solution can completely solve the reproducibility crisis of medical deep learning research, due to a variety of issues ranging from ambiguous data processing techniques to stochasticity of model training. However, community-centered open-source solutions and increased clinical adherence to data standards, such as contour nomenclature, 15 can incrementally improve research quality and reproducibility, and make medical deep learning research more accessible for everyone. Q: Finally, specifically, for the RADCURE dataset, it is not clear to me why you are comparing run time on a single core versus run time on a 32 core machine. I suspect the reported run time for the comparison could be significantly reduced by using a very simple parallelization which should be achievable tools available in python. I would suggest a fairer comparison for this specific example, it wont detract from the best argument you have which is there you are presenting a nice package so that other developers and researchers do not have to spend time re-writing code. Highlighting where some time savings may be gained is in some ways a secondary advantage. A: We thank the reviewer for their comment about Figure 2d. The goal of the comparison was not only to show a reduction in processing time based on parallelization, but to show that our package’s design does not bottleneck any multiprocessing backends and brings meaningful acceleration on large datasets. In other words, we wanted to show that a 32x increase in computational hardware was going to bring at least 32x improvement in performance as observed in Figure 2d. This is in contrast to Figure 2c which does not show similar levels hardware acceleration, but its usefulness in parsing private, unseen data. We have expanded on these ideas in the manuscript as follows: In contrast, on the same 6-core machine (16GB RAM, Windows 10), AutoPipeline took only 2.3 hours with 1 command line, mainly accelerated by parallelization ( Figure 2c). The authors involved in validating Med-ImageTools' effectiveness on this private dataset had no active involvement in the development of the package before its application. This highlights the package’s robustness on unseen data and its potential utility for multi-centre collaborations to ensure consistent processing. One use case might be to enable federated learning platforms to automatically process each node’s datasets without requiring any user intervention. AutoPipeline scales dramatically based on the number of cores available, which enables the entire dataset to be processed in 40 minutes using 32 cores, automatically managing the directories from different systems and extracting the contours ( Figure 2d). These results demonstrate Med-ImageTools' design does not bottleneck any multiprocessing backends and brings meaningful acceleration on very large datasets, such as RADCURE. Q: Finally, as a minor note the statement that SlicerRT is not easily interfaced with python is not a fully justified statement. One can use the python interface in Slicer to run python scripts and even run from the command prompt by called s'licer.exe --python-code'. However, I think you can modify this to make a true and equally motivated statement which is that SlicerRT requires one to install Slicer/SlicerRT and stay within the slicer ecosystem to process data. Your tool lacks such dependencies so can be a more light weight and does not require running python through another software system. A: We thank the reviewer for this point. We have revised the relevant section from ‘Current Workflows’ as follows to better justify our statement. Despite its broad adoption, batch data processing with Slicer requires custom scripting in Python, to be executed in the Slicer ecosystem. Rather than simply installing a package within their Python environment, users must install the Slicer application and add any other dependencies, not provided by Slicer, into the application environment. As a result, machine learning projects relying on Python for data preprocessing will have their code fragmented across multiple environments–the Slicer environment for data processing, and another Python environment for data analysis and machine learning. We thank Dr Sparks for her feedback regarding our manuscript titled ‘Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data’. We have added our responses to their comments here in subdivided sections of comments/questions (Q), in bold, our corresponding responses/answers (A), and any relevant sections of the manuscript as an italicized bullet point, with changes emphasized in bold. Q: I think the motivation and justification for why a light weight Python module to support data loading and preprocessing of radiotherapy DICOM formats was very well articulated and clear. And I applaud the authors on making such a useful tool available to the community. A: We thank the reviewer for their recognition of Med-ImageTools’ contribution to the medical imaging community and positively evaluating the authors’ works. Q: However, I have two major concerns that must be addressed prior to this article being acceptable for indexing. First there are no details as to the design of Med-Image-Tools this includes important information such as: (1) dependencies on other python packages A: We thank the reviewer for pointing out the need to communicate the technical dependencies of Med-ImageTools. We have updated our ‘AutoPipeline’ section as follows, to include information on how to find the list of package dependencies. Running the ‘ pip install med-imagetools’ command will install the latest version of Med-ImageTools and its associated dependencies defined by the requirements.txt file. The ‘Current workflows’ section also contains a concise description of what frameworks Med-ImageTools leverages such as follows: While Med-ImageTools has many modular functions for image, contour, and dose input/output (IO) built on popular frameworks such as SimpleITK, TorchIO and PyDicom… Q: (2) what functions or other tools are being leveraged within the tool and how these are arranged. A: We thank the reviewer for calling attention to the need to clarify how other tools/packages function within Med-ImageTools. We have added some information to our ‘AutoPipeline’ section to clarify major operations performed using external tools/packages as follows. For a granular understanding of the integration behind every external tool, we defer the reader to learn about the design choices made throughout the package and its implications by gaining a deeper understanding of the source code available through our GitHub repository. 1. Crawl: The crawler opens every DICOM file in the dataset using Pydicom, indexing important metadata, such as unique identifiers, modality information, and references to other modalities. This produces a database of every unique image and DICOM-RT modality. 3. Process: All identified samples are processed according to imaging and transformation parameters defined by the user. The user can configure parameters such as the pixel spacing in mm(s), which specific modalities to process, the number of cores they want to use for multiprocessing, and define nnU-Net specific flags as well. The images are manipulated using SimpleITK without requiring user intervention. As the crawl and process steps are computationally intensive, all steps in AutoPipeline are automatically parallelized using the joblib backend to efficiently leverage all available computational resources. Q: (3) the structure of the outputs of this pipeline specifically the csv file corresponding to the 'Dataset Index', the imaging and non-imaging feature outputs. For instance for imaging data how are pre-operative scans and segmentations saved and named (is there a convention is this something the user must write) A: We thank the reviewer for this question and for highlighting the lack of clarity of our description of AutoPipeline. The ‘Dataset Index’ is designed to be an autogenerated output of the Crawler and does not require any user interaction to be created; this is simply there to ensure convenient user experience. We have made this and other aspects of the outputs clearer by adding the following sentences to the ‘AutoPipeline’ section. Med-ImageTools also generates files that are not analysis-ready images, such as the autogenerated ‘Dataset Index’ (Figure 1), and stores them in a folder named “.imgtools” at the path of the ‘input_directory’. This is to ensure a convenient user experience and intuitive folder structure by hiding extraneous components. Q: (4) While there is a reference to the tutorial about the processing pipeline I think a high level overview listing the possible options would be appropriate to help the reader understand what this tool can offer. A: We agree with the reviewer that adding this information to our description of AutoPipeline can help readers quickly understand the tool’s strengths before interfacing with the GitHub repository or ReadTheDocs. We have updated the ‘AutoPipeline’ section accordingly. 3. Process: All identified samples are processed according to imaging and transformation parameters defined by the user. The user can configure parameters such as: the pixel spacing in mm(s), which specific modalities to process, the number of cores they want to use for multiprocessing, and define nnU-Net specific flags as well. The images are manipulated using SimpleITK without requiring user intervention. Q: My other concern is related to the use cases. While lines of code is an easy metric to report it is mostly meaningless, some lines of code may be boilerplate or easy to write while others may obviously be different. It is also easy to pad or alter depending on the level of skill of the programmer. I think reporting run time is far more meaningful to your argument and I would stick to these. A: We appreciate the reviewer’s consideration in the metrics reported in Figure 2. However, we believe this metric emphasizes Med-ImageTools’ strength allowing users to process DICOM datasets with a single command line interaction, in contrast to writing dozens of lines of Python/R/MATLAB scripts. One particular reason why we believe a single command line is useful to highlight is to express the ease-of-use for users that may not be comfortable writing their own code for DICOM to NifTI/Nrrd processing, especially if they lack deep domain knowledge. Another, perhaps more, exciting reason is to show the potential of building automated workflows on top of Med-ImageTools. If one were to build an end-to-end automated pipeline starting from clinical DICOM datasets to outputting an inference-ready deep learning model, they could easily develop a reproducible processing step by configuring only the command line interaction of Med-ImageTools, making debugging and custom configurations simpler since the developer would not have to rely on a static script. We have elaborated on Med-ImageTools’ contributions for improved scientific reproducibility in the ‘Discussion’ section as follows. The AutoPipeline feature will improve the accessibility of raw clinical datasets on public archives, such as TCIA, allowing machine learning researchers to process analysis-ready formats without requiring deep domain knowledge. Another exciting potential of Med-ImageTools lies in building automated workflows using AutoPipeline. For a researcher to build an end-to-end automated pipeline starting from clinical DICOM datasets to outputting an inference-ready deep learning model, they could easily develop a reproducible processing step by configuring only the command line interaction of Med-ImageTools, making debugging and custom configurations simpler since the developer would not have to rely on a static script. No single solution can completely solve the reproducibility crisis of medical deep learning research, due to a variety of issues ranging from ambiguous data processing techniques to stochasticity of model training. However, community-centered open-source solutions and increased clinical adherence to data standards, such as contour nomenclature, 15 can incrementally improve research quality and reproducibility, and make medical deep learning research more accessible for everyone. Q: Finally, specifically, for the RADCURE dataset, it is not clear to me why you are comparing run time on a single core versus run time on a 32 core machine. I suspect the reported run time for the comparison could be significantly reduced by using a very simple parallelization which should be achievable tools available in python. I would suggest a fairer comparison for this specific example, it wont detract from the best argument you have which is there you are presenting a nice package so that other developers and researchers do not have to spend time re-writing code. Highlighting where some time savings may be gained is in some ways a secondary advantage. A: We thank the reviewer for their comment about Figure 2d. The goal of the comparison was not only to show a reduction in processing time based on parallelization, but to show that our package’s design does not bottleneck any multiprocessing backends and brings meaningful acceleration on large datasets. In other words, we wanted to show that a 32x increase in computational hardware was going to bring at least 32x improvement in performance as observed in Figure 2d. This is in contrast to Figure 2c which does not show similar levels hardware acceleration, but its usefulness in parsing private, unseen data. We have expanded on these ideas in the manuscript as follows: In contrast, on the same 6-core machine (16GB RAM, Windows 10), AutoPipeline took only 2.3 hours with 1 command line, mainly accelerated by parallelization ( Figure 2c). The authors involved in validating Med-ImageTools' effectiveness on this private dataset had no active involvement in the development of the package before its application. This highlights the package’s robustness on unseen data and its potential utility for multi-centre collaborations to ensure consistent processing. One use case might be to enable federated learning platforms to automatically process each node’s datasets without requiring any user intervention. AutoPipeline scales dramatically based on the number of cores available, which enables the entire dataset to be processed in 40 minutes using 32 cores, automatically managing the directories from different systems and extracting the contours ( Figure 2d). These results demonstrate Med-ImageTools' design does not bottleneck any multiprocessing backends and brings meaningful acceleration on very large datasets, such as RADCURE. Q: Finally, as a minor note the statement that SlicerRT is not easily interfaced with python is not a fully justified statement. One can use the python interface in Slicer to run python scripts and even run from the command prompt by called s'licer.exe --python-code'. However, I think you can modify this to make a true and equally motivated statement which is that SlicerRT requires one to install Slicer/SlicerRT and stay within the slicer ecosystem to process data. Your tool lacks such dependencies so can be a more light weight and does not require running python through another software system. A: We thank the reviewer for this point. We have revised the relevant section from ‘Current Workflows’ as follows to better justify our statement. Despite its broad adoption, batch data processing with Slicer requires custom scripting in Python, to be executed in the Slicer ecosystem. Rather than simply installing a package within their Python environment, users must install the Slicer application and add any other dependencies, not provided by Slicer, into the application environment. As a result, machine learning projects relying on Python for data preprocessing will have their code fragmented across multiple environments–the Slicer environment for data processing, and another Python environment for data analysis and machine learning. Competing Interests: There are no competing interests to disclose. Close Report a concern COMMENT ON THIS REPORT Comments on this article Comments (0) Version 3 VERSION 3 PUBLISHED 01 Feb 2023 ADD YOUR COMMENT Comment keyboard_arrow_left keyboard_arrow_right Open Peer Review Reviewer Status info_outline Alongside their report, reviewers assign a status to the article: Approved The paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved Fundamental flaws in the paper seriously undermine the findings and conclusions Reviewer Reports Invited Reviewers 1 2 Version 3 (revision) 07 Feb 25 read Version 2 (revision) 07 May 24 read read Version 1 01 Feb 23 read read Rachel Sparks , King's College London, London, UK Johann Faouzi , ENSAI, Rennes, France Comments on this article All Comments (0) Add a comment Sign up for content alerts Sign Up You are now signed up to receive this alert Browse by related subjects keyboard_arrow_left Back to all reports Reviewer Report 0 Views copyright © 2025 Faouzi J. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. 22 Feb 2025 | for Version 3 Johann Faouzi , ENSAI, Rennes, France 0 Views copyright © 2025 Faouzi J. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. format_quote Cite this report speaker_notes Responses (0) Approved info_outline Alongside their report, reviewers assign a status to the article: Approved The paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved Fundamental flaws in the paper seriously undermine the findings and conclusions I would like to thank the authors for their detailed response. The software development aspects have been substantially improved since the previous version, and I am happy to approve the current version of the article. Competing Interests No competing interests were disclosed. Reviewer Expertise Open source software, Python programming, machine learning, medical applications I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard. reply Respond to this report Responses (0) Faouzi J. Peer Review Report For: Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data [version 3; peer review: 2 approved] . F1000Research 2025, 12 :118 ( https://doi.org/10.5256/f1000research.177718.r366375) NOTE: it is important to ensure the information in square brackets after the title is included in this citation. The direct URL for this report is: https://f1000research.com/articles/12-118/v3#referee-response-366375 keyboard_arrow_left Back to all reports Reviewer Report 0 Views copyright © 2024 Sparks R. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. 12 Jun 2024 | for Version 2 Rachel Sparks , King's College London, London, England, UK 0 Views copyright © 2024 Sparks R. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. format_quote Cite this report speaker_notes Responses (0) Approved info_outline Alongside their report, reviewers assign a status to the article: Approved The paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved Fundamental flaws in the paper seriously undermine the findings and conclusions I am happy with the revisions made to the document and responses to my specific queries. Competing Interests No competing interests were disclosed. Reviewer Expertise Software development; open source software; medical image computing I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard. reply Respond to this report Responses (0) Sparks R. Peer Review Report For: Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data [version 3; peer review: 2 approved] . F1000Research 2025, 12 :118 ( https://doi.org/10.5256/f1000research.164713.r274815) NOTE: it is important to ensure the information in square brackets after the title is included in this citation. The direct URL for this report is: https://f1000research.com/articles/12-118/v2#referee-response-274815 keyboard_arrow_left Back to all reports Reviewer Report 0 Views copyright © 2024 Faouzi J. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. 15 May 2024 | for Version 2 Johann Faouzi , ENSAI, Rennes, France 0 Views copyright © 2024 Faouzi J. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. format_quote Cite this report speaker_notes Responses (1) Approved With Reservations info_outline Alongside their report, reviewers assign a status to the article: Approved The paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved Fundamental flaws in the paper seriously undermine the findings and conclusions I would like to thank the authors for replying to all my comments. I think that the manuscript has been improved since the first version. Nonetheless, I still have some concerns regarding the source code. Despite some cleaning, there are still numerous flake8 errors. Flake8 is not used in the CI even though it is installed. Code coverage is still not included in the CI. PR with failing CI are still merged into in the main branch. Overall, the software aspect of this contribution, which is the main contribution, has still important limitations. Competing Interests No competing interests were disclosed. Reviewer Expertise Open source software, Python programming, machine learning, medical applications I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard, however I have significant reservations, as outlined above. reply Respond to this report Responses (1) Author Response 14 Jun 2024 Benjamin Haibe-Kains, Princess Margaret Cancer Centre, Canada Thank you Dr Faouzi for your feedback regarding our CI/CD pipeline and we are glad to inform you that we have made the appropriate updates. We have switched from flake8 to ruff (Rust-based Python linter) as our main linter and have made appropriate modifications to our codebase to address all linting issues. The linter is also integrated into the CI/CD pipeline as well. The main failure of our previous tests was due to the deprecation of .egg uploads to PyPI, despite the unit tests always passing. We have resolved these issues by rewriting our CI/CD pipeline, which has led to reliable tests and continuous deployments to PyPI. We have also incorporated code coverage into our CI/CD pipeline and have added a badge to the README. While the current code coverage of the tests is still low, we believe after our upcoming refactoring efforts, the coverage of the tests will significantly improve. Finally, we have implemented semantic versioning to our package to adhere to industry standards and ensure consistent, trackable versioning changes. View more View less Competing Interests No competing interests were disclosed. reply Respond Report a concern Faouzi J. Peer Review Report For: Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data [version 3; peer review: 2 approved] . F1000Research 2025, 12 :118 ( https://doi.org/10.5256/f1000research.164713.r274816) NOTE: it is important to ensure the information in square brackets after the title is included in this citation. The direct URL for this report is: https://f1000research.com/articles/12-118/v2#referee-response-274816 keyboard_arrow_left Back to all reports Reviewer Report 0 Views copyright © 2023 Faouzi J. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. 17 Oct 2023 | for Version 1 Johann Faouzi , ENSAI, Rennes, France 0 Views copyright © 2023 Faouzi J. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. format_quote Cite this report speaker_notes Responses (1) Approved With Reservations info_outline Alongside their report, reviewers assign a status to the article: Approved The paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved Fundamental flaws in the paper seriously undermine the findings and conclusions The authors present their Python package for data processing pipelines and curating medical imaging data in this manuscript. Overall the manuscript is well written and clearly presents the main contributions of this package to the community. Nonetheless, some points on the software side could be improved. Please find my comments below: * How does the output format used compare to other formats such as other popular formats such as BIDS (Brain Imaging Data Structure, which is maybe less general since it's intended for brain imaging data)? * Figure 2b (and the corresponding text): Raw saved running time, even though useful, is irrelevant without knowing the total running time. Please provide also the saved time as a percentage of the total running time. * Figures 2c and 2d: "1 lines" => "1 line" * The authors should consider renaming the "master" branch as the "main" branch (see https://sfconservancy.org/news/2020/jun/23/gitbranchname/). * Is there a reason for Python 3.8 not being tested in the continuous integration (CI) (maybe a limit on the number of jobs)? By the way, Python 3.7 is no longer supported and Python 3.11 has been released for over 9 months (https://devguide.python.org/versions/). The Python versions tested in the CI should probably be updated. * Flake8 is installed in the CI but never used. I ran the command locally (flake8 | wc -l) and obtained 2163 errors or warnings, which is not good. It would be nice to clean the source code a bit. * There is no code coverage associated to the tests, which is an important limitation. Please add code coverage to your project. There are "only" 16 tests for the moment, so I suspect that a substantial part of the source code is not tested. * I don't understand the point of using the "-s" option with pytest. I don't find the output (when using this option) to be clear or useful to identify tests that would fail for instance. In particular, I don't think that printing stuff when running the tests in the CI is relevant. Is the rationale for developing the new software tool clearly explained? Yes Is the description of the software tool technically sound? Yes Are sufficient details of the code, methods and analysis (if applicable) provided to allow replication of the software development and its use by others? Yes Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool? Yes Are the conclusions about the tool and its performance adequately supported by the findings presented in the article? Yes Competing Interests No competing interests were disclosed. Reviewer Expertise Open source software, Python programming, machine learning, medical applications I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard, however I have significant reservations, as outlined above. reply Respond to this report Responses (1) Author Response 07 May 2024 Benjamin Haibe-Kains, Princess Margaret Cancer Centre, Canada We thank Dr Faouzi for his feedback regarding our manuscript titled ‘Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data’. We have added our responses to their comments here in subdivided sections of comments/questions (Q), in bold, our corresponding responses/answers (A), and any relevant sections of the manuscript as an italicized bullet point, with changes emphasized in bold. Q: The authors present their Python package for data processing pipelines and curating medical imaging data in this manuscript. Overall the manuscript is well written and clearly presents the main contributions of this package to the community. Nonetheless, some points on the software side could be improved. Please find my comments below: A: We thank the reviewer for their positive understanding of the authors’ work and constructive feedback, especially on the technical aspects of the package. Q: How does the output format used compare to other formats such as other popular formats such as BIDS (Brain Imaging Data Structure, which is maybe less general since it's intended for brain imaging data)? A: We thank the reviewer for bringing the BIDS standard to the authors’ attention. The BIDS standard is very effective in standardizing brain imaging datasets by adhering to an intuitive structure describing various modalities of brain MRI. Med-ImageTools is mainly geared towards use cases that are broader and less specific than BIDS and its implementation would require fundamental reworkings of the package. However, the benefit of having a BIDS-native output cannot be understated and this feature will be added to the development team’s ongoing development goals. We have revised the relevant section from ‘Current Workflows’ as follows: While Med-ImageTools has many modular functions for image, contour, and dose input/output (IO) built on popular frameworks such as SimpleITK, TorchIO and PyDicom, such functionalities are redundant and available in other open-source packages as well. We have tailored our core features towards broader use cases and development workflows, instead of modality or disease type specific workflows, such as BIDS. Our main contribution is in the development of AutoPipeline and will mainly discuss its functionalities and implementation. Q: Figure 2b (and the corresponding text): Raw saved running time, even though useful, is irrelevant without knowing the total running time. Please provide also the saved time as a percentage of the total running time. A: We appreciate the reviewer’s point about Figure 2b. However, the reported time saved is reported in core-hours, which is a comprehensive unit of total running time. This is because the crawling occurred independently from the end-to-end processing of the datasets to ensure an accurate measure of core-hours saved. Reporting core-hours saved allows the reader to estimate their time/cost savings based on their specific hardware availabilities, either local machine, server-based, or cloud infrastructure, agnOSTIC to the hardware used by the authors. We have emphasIZED this point in our manuscRIPT as fOLLOWS: However, when scaled up to larger TCIA datasets such as OPC-Radiomics 13 (n=606) and NLST 14 (n=26254), it can save researchers 24.7 core-hours and 1072 core-hours, respectively (Figure 2b). The resources saved are reported in core-hours to allow a hardware-agnostic estimation of time and cost savings. While it may vary depending on the research infrastructure utilized, these databases can result in significant savings in billing. Q: Figures 2c and 2d: "1 lines" => "1 line" Q: The authors should consider renaming the "master" branch as the "main" branch (see https://sfconservancy.org/news/2020/jun/23/gitbranchname/). Q: Is there a reason for Python 3.8 not being tested in the continuous integration (CI) (maybe a limit on the number of jobs)? By the way, Python 3.7 is no longer supported and Python 3.11 has been released for over 9 months (https://devguide.python.org/versions/). The Python versions tested in the CI should probably be updated. A: We thank the reviewer for their comments. The figures and repository have been updated to address these points. Q: Flake8 is installed in the CI but never used. I ran the command locally (flake8 | wc -l) and obtained 2163 errors or warnings, which is not good. It would be nice to clean the source code a bit. A: We thank the reviewer for raising the concern about the source code’s sanitation. The authors have reviewed the flake8 output and incorporated it into our codebase. You can find all changes in the following commit: https://github.com/bhklab/med-imagetools/commit/a8c0c3be53b4c9b43da12603b222d261d417a18c . Q: I don't understand the point of using the "-s" option with pytest. I don't find the output (when using this option) to be clear or useful to identify tests that would fail for instance. In particular, I don't think that printing stuff when running the tests in the CI is relevant. A: We thank the reviewer’s attention to detail in Med-ImageTools’ CI/CD framework. The -s option is enabled for verbose outputs from Med-ImageTools to be carried through to the standard output of the tests in CI. In the past we have had OS-specific issues that were elucidated through the -s flag, but have removed it for future releases. Q: There is no code coverage associated to the tests, which is an important limitation. Please add code coverage to your project. There are "only" 16 tests for the moment, so I suspect that a substantial part of the source code is not tested. A: We thank the reviewer for highlighting the lack of code coverage association of these tests. We agree that this is a clear limitation of the Med-ImageTools’ development pipeline, and have significantly increased the number of unit tests and integrated them into our CI/CD process. Future development efforts will continue to add more tests to our pipeline, including a badge detailing code coverage on our README. View more View less Competing Interests There are no competing interests to disclose. reply Respond Report a concern Faouzi J. Peer Review Report For: Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data [version 3; peer review: 2 approved] . F1000Research 2025, 12 :118 ( https://doi.org/10.5256/f1000research.139617.r189038) NOTE: it is important to ensure the information in square brackets after the title is included in this citation. The direct URL for this report is: https://f1000research.com/articles/12-118/v1#referee-response-189038 keyboard_arrow_left Back to all reports Reviewer Report 0 Views copyright © 2023 Sparks R. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. 17 Oct 2023 | for Version 1 Rachel Sparks , King's College London, London, England, UK 0 Views copyright © 2023 Sparks R. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License , which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. format_quote Cite this report speaker_notes Responses (1) Approved With Reservations info_outline Alongside their report, reviewers assign a status to the article: Approved The paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved Fundamental flaws in the paper seriously undermine the findings and conclusions I think the motivation and justification for why a light weight Python module to support data loading and preprocessing of radiotherapy DICOM formats was very well articulated and clear. And I applaud the authors on making such a useful tool available to the community. However, I have two major concerns that must be addressed prior to this article being acceptable for indexing. First there are no details as to the design of Med-Image-Tools this includes important information such as: (1) dependencies on other python packages (2) what functions or other tools are being leveraged within the tool and how these are arranged. (3) the structure of the outputs of this pipeline specifically the csv file corresponding to the 'Dataset Index', the imaging and non-imaging feature outputs. For instance for imaging data how are pre-operative scans and segmentations saved and named (is there a convention is this something the user must write) (4) While there is a reference to the tutorial about the processing pipeline I think a high level overview listing the possible options would be appropriate to help the reader understand what this tool can offer. My other concern is related to the use cases. While lines of code is an easy metric to report it is mostly meaningless, some lines of code may be boilerplate or easy to write while others may obviously be different. It is also easy to pad or alter depending on the level of skill of the programmer. I think reporting run time is far more meaningful to your argument and I would stick to these. Finally, specifically, for the RADCURE dataset, it is not clear to me why you are comparing run time on a single core versus run time on a 32 core machine. I suspect the reported run time for the comparison could be significantly reduced by using a very simple parallelization which should be achievable tools available in python. I would suggest a fairer comparison for this specific example, it wont detract from the best argument you have which is there you are presenting a nice package so that other developers and researchers do not have to spend time re-writing code. Highlighting where some time savings may be gained is in some ways a secondary advantage. Finally, as a minor note the statement that SlicerRT is not easily interfaced with python is not a fully justified statement. One can use the python interface in Slicer to run python scripts and even run from the command prompt by called s'licer.exe --python-code'. However, I think you can modify this to make a true and equally motivated statement which is that SlicerRT requires one to install Slicer/SlicerRT and stay within the slicer ecosystem to process data. Your tool lacks such dependencies so can be a more light weight and does not require running python through another software system. Is the rationale for developing the new software tool clearly explained? Yes Is the description of the software tool technically sound? No Are sufficient details of the code, methods and analysis (if applicable) provided to allow replication of the software development and its use by others? No Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool? No Are the conclusions about the tool and its performance adequately supported by the findings presented in the article? Yes Competing Interests No competing interests were disclosed. Reviewer Expertise Software development; open source software; medical image computing I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard, however I have significant reservations, as outlined above. reply Respond to this report Responses (1) Author Response 07 May 2024 Benjamin Haibe-Kains, Princess Margaret Cancer Centre, Canada We thank Dr Sparks for her feedback regarding our manuscript titled ‘Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data’. We have added our responses to their comments here in subdivided sections of comments/questions (Q), in bold, our corresponding responses/answers (A), and any relevant sections of the manuscript as an italicized bullet point, with changes emphasized in bold. Q: I think the motivation and justification for why a light weight Python module to support data loading and preprocessing of radiotherapy DICOM formats was very well articulated and clear. And I applaud the authors on making such a useful tool available to the community. A: We thank the reviewer for their recognition of Med-ImageTools’ contribution to the medical imaging community and positively evaluating the authors’ works. Q: However, I have two major concerns that must be addressed prior to this article being acceptable for indexing. First there are no details as to the design of Med-Image-Tools this includes important information such as: (1) dependencies on other python packages A: We thank the reviewer for pointing out the need to communicate the technical dependencies of Med-ImageTools. We have updated our ‘AutoPipeline’ section as follows, to include information on how to find the list of package dependencies. Running the ‘ pip install med-imagetools’ command will install the latest version of Med-ImageTools and its associated dependencies defined by the requirements.txt file. The ‘Current workflows’ section also contains a concise description of what frameworks Med-ImageTools leverages such as follows: While Med-ImageTools has many modular functions for image, contour, and dose input/output (IO) built on popular frameworks such as SimpleITK, TorchIO and PyDicom… Q: (2) what functions or other tools are being leveraged within the tool and how these are arranged. A: We thank the reviewer for calling attention to the need to clarify how other tools/packages function within Med-ImageTools. We have added some information to our ‘AutoPipeline’ section to clarify major operations performed using external tools/packages as follows. For a granular understanding of the integration behind every external tool, we defer the reader to learn about the design choices made throughout the package and its implications by gaining a deeper understanding of the source code available through our GitHub repository. 1. Crawl: The crawler opens every DICOM file in the dataset using Pydicom, indexing important metadata, such as unique identifiers, modality information, and references to other modalities. This produces a database of every unique image and DICOM-RT modality. 3. Process: All identified samples are processed according to imaging and transformation parameters defined by the user. The user can configure parameters such as the pixel spacing in mm(s), which specific modalities to process, the number of cores they want to use for multiprocessing, and define nnU-Net specific flags as well. The images are manipulated using SimpleITK without requiring user intervention. As the crawl and process steps are computationally intensive, all steps in AutoPipeline are automatically parallelized using the joblib backend to efficiently leverage all available computational resources. Q: (3) the structure of the outputs of this pipeline specifically the csv file corresponding to the 'Dataset Index', the imaging and non-imaging feature outputs. For instance for imaging data how are pre-operative scans and segmentations saved and named (is there a convention is this something the user must write) A: We thank the reviewer for this question and for highlighting the lack of clarity of our description of AutoPipeline. The ‘Dataset Index’ is designed to be an autogenerated output of the Crawler and does not require any user interaction to be created; this is simply there to ensure convenient user experience. We have made this and other aspects of the outputs clearer by adding the following sentences to the ‘AutoPipeline’ section. Med-ImageTools also generates files that are not analysis-ready images, such as the autogenerated ‘Dataset Index’ (Figure 1), and stores them in a folder named “.imgtools” at the path of the ‘input_directory’. This is to ensure a convenient user experience and intuitive folder structure by hiding extraneous components. Q: (4) While there is a reference to the tutorial about the processing pipeline I think a high level overview listing the possible options would be appropriate to help the reader understand what this tool can offer. A: We agree with the reviewer that adding this information to our description of AutoPipeline can help readers quickly understand the tool’s strengths before interfacing with the GitHub repository or ReadTheDocs. We have updated the ‘AutoPipeline’ section accordingly. 3. Process: All identified samples are processed according to imaging and transformation parameters defined by the user. The user can configure parameters such as: the pixel spacing in mm(s), which specific modalities to process, the number of cores they want to use for multiprocessing, and define nnU-Net specific flags as well. The images are manipulated using SimpleITK without requiring user intervention. Q: My other concern is related to the use cases. While lines of code is an easy metric to report it is mostly meaningless, some lines of code may be boilerplate or easy to write while others may obviously be different. It is also easy to pad or alter depending on the level of skill of the programmer. I think reporting run time is far more meaningful to your argument and I would stick to these. A: We appreciate the reviewer’s consideration in the metrics reported in Figure 2. However, we believe this metric emphasizes Med-ImageTools’ strength allowing users to process DICOM datasets with a single command line interaction, in contrast to writing dozens of lines of Python/R/MATLAB scripts. One particular reason why we believe a single command line is useful to highlight is to express the ease-of-use for users that may not be comfortable writing their own code for DICOM to NifTI/Nrrd processing, especially if they lack deep domain knowledge. Another, perhaps more, exciting reason is to show the potential of building automated workflows on top of Med-ImageTools. If one were to build an end-to-end automated pipeline starting from clinical DICOM datasets to outputting an inference-ready deep learning model, they could easily develop a reproducible processing step by configuring only the command line interaction of Med-ImageTools, making debugging and custom configurations simpler since the developer would not have to rely on a static script. We have elaborated on Med-ImageTools’ contributions for improved scientific reproducibility in the ‘Discussion’ section as follows. The AutoPipeline feature will improve the accessibility of raw clinical datasets on public archives, such as TCIA, allowing machine learning researchers to process analysis-ready formats without requiring deep domain knowledge. Another exciting potential of Med-ImageTools lies in building automated workflows using AutoPipeline. For a researcher to build an end-to-end automated pipeline starting from clinical DICOM datasets to outputting an inference-ready deep learning model, they could easily develop a reproducible processing step by configuring only the command line interaction of Med-ImageTools, making debugging and custom configurations simpler since the developer would not have to rely on a static script. No single solution can completely solve the reproducibility crisis of medical deep learning research, due to a variety of issues ranging from ambiguous data processing techniques to stochasticity of model training. However, community-centered open-source solutions and increased clinical adherence to data standards, such as contour nomenclature, 15 can incrementally improve research quality and reproducibility, and make medical deep learning research more accessible for everyone. Q: Finally, specifically, for the RADCURE dataset, it is not clear to me why you are comparing run time on a single core versus run time on a 32 core machine. I suspect the reported run time for the comparison could be significantly reduced by using a very simple parallelization which should be achievable tools available in python. I would suggest a fairer comparison for this specific example, it wont detract from the best argument you have which is there you are presenting a nice package so that other developers and researchers do not have to spend time re-writing code. Highlighting where some time savings may be gained is in some ways a secondary advantage. A: We thank the reviewer for their comment about Figure 2d. The goal of the comparison was not only to show a reduction in processing time based on parallelization, but to show that our package’s design does not bottleneck any multiprocessing backends and brings meaningful acceleration on large datasets. In other words, we wanted to show that a 32x increase in computational hardware was going to bring at least 32x improvement in performance as observed in Figure 2d. This is in contrast to Figure 2c which does not show similar levels hardware acceleration, but its usefulness in parsing private, unseen data. We have expanded on these ideas in the manuscript as follows: In contrast, on the same 6-core machine (16GB RAM, Windows 10), AutoPipeline took only 2.3 hours with 1 command line, mainly accelerated by parallelization ( Figure 2c). The authors involved in validating Med-ImageTools' effectiveness on this private dataset had no active involvement in the development of the package before its application. This highlights the package’s robustness on unseen data and its potential utility for multi-centre collaborations to ensure consistent processing. One use case might be to enable federated learning platforms to automatically process each node’s datasets without requiring any user intervention. AutoPipeline scales dramatically based on the number of cores available, which enables the entire dataset to be processed in 40 minutes using 32 cores, automatically managing the directories from different systems and extracting the contours ( Figure 2d). These results demonstrate Med-ImageTools' design does not bottleneck any multiprocessing backends and brings meaningful acceleration on very large datasets, such as RADCURE. Q: Finally, as a minor note the statement that SlicerRT is not easily interfaced with python is not a fully justified statement. One can use the python interface in Slicer to run python scripts and even run from the command prompt by called s'licer.exe --python-code'. However, I think you can modify this to make a true and equally motivated statement which is that SlicerRT requires one to install Slicer/SlicerRT and stay within the slicer ecosystem to process data. Your tool lacks such dependencies so can be a more light weight and does not require running python through another software system. A: We thank the reviewer for this point. We have revised the relevant section from ‘Current Workflows’ as follows to better justify our statement. Despite its broad adoption, batch data processing with Slicer requires custom scripting in Python, to be executed in the Slicer ecosystem. Rather than simply installing a package within their Python environment, users must install the Slicer application and add any other dependencies, not provided by Slicer, into the application environment. As a result, machine learning projects relying on Python for data preprocessing will have their code fragmented across multiple environments–the Slicer environment for data processing, and another Python environment for data analysis and machine learning. View more View less Competing Interests There are no competing interests to disclose. reply Respond Report a concern Sparks R. Peer Review Report For: Med-ImageTools: An open-source Python package for robust data processing pipelines and curating medical imaging data [version 3; peer review: 2 approved] . F1000Research 2025, 12 :118 ( https://doi.org/10.5256/f1000research.139617.r189015) NOTE: it is important to ensure the information in square brackets after the title is included in this citation. The direct URL for this report is: https://f1000research.com/articles/12-118/v1#referee-response-189015 Alongside their report, reviewers assign a status to the article: Approved - the paper is scientifically sound in its current form and only minor, if any, improvements are suggested Approved with reservations - A number of small changes, sometimes more significant revisions are required to address specific details and improve the papers academic merit. Not approved - fundamental flaws in the paper seriously undermine the findings and conclusions Adjust parameters to alter display View on desktop for interactive features Includes Interactive Elements View on desktop for interactive features Competing Interests Policy Provide sufficient details of any financial or non-financial competing interests to enable users to assess whether your comments might lead a reasonable person to question your impartiality. Consider the following examples, but note that this is not an exhaustive list: Examples of 'Non-Financial Competing Interests' Within the past 4 years, you have held joint grants, published or collaborated with any of the authors of the selected paper. You have a close personal relationship (e.g. parent, spouse, sibling, or domestic partner) with any of the authors. You are a close professional associate of any of the authors (e.g. scientific mentor, recent student). You work at the same institute as any of the authors. You hope/expect to benefit (e.g. favour or employment) as a result of your submission. You are an Editor for the journal in which the article is published. Examples of 'Financial Competing Interests' You expect to receive, or in the past 4 years have received, any of the following from any commercial organisation that may gain financially from your submission: a salary, fees, funding, reimbursements. You expect to receive, or in the past 4 years have received, shared grant support or other funding with any of the authors. You hold, or are currently applying for, any patents or significant stocks/shares relating to the subject matter of the paper you are commenting on. Stay Updated Sign up for content alerts and receive a weekly or monthly email with all newly published articles Register with F1000Research Already registered? Sign in Not now, thanks close PLEASE NOTE If you are an AUTHOR of this article, please check that you signed in with the account associated with this article otherwise we cannot automatically identify your role as an author and your comment will be labelled as a “User Comment”. If you are a REVIEWER of this article, please check that you have signed in with the account associated with this article and then go to your account to submit your report, please do not post your review here. If you do not have access to your original account, please contact us . All commenters must hold a formal affiliation as per our Policies . The information that you give us will be displayed next to your comment. User comments must be in English, comprehensible and relevant to the article under discussion. We reserve the right to remove any comments that we consider to be inappropriate, offensive or otherwise in breach of the User Comment Terms and Conditions . Commenters must not use a comment for personal attacks. When criticisms of the article are based on unpublished data, the data should be made available. I accept the User Comment Terms and Conditions Please confirm that you accept the User Comment Terms and Conditions. Affiliation ✕ refresh Please enter your institution. Note: To add your institution or organisation, start typing the name and then select the correct name from the list. Where applicable, the name will appear in both the original language and in English. Do not paste in the name. If the name does not appear in the drop-down list, we will display the information you have entered. ✕ refresh Country/Region * USA UK Canada China France Germany Afghanistan Aland Islands Albania Algeria American Samoa Andorra Angola Anguilla Antarctica Antigua and Barbuda Argentina Armenia Aruba Australia Austria Azerbaijan Bahamas Bahrain Bangladesh Barbados Belarus Belgium Belize Benin Bermuda Bhutan Bolivia Bosnia and Herzegovina Botswana Bouvet Island Brazil British Indian Ocean Territory British Virgin Islands Brunei Bulgaria Burkina Faso Burundi Cambodia Cameroon Canada Cape Verde Cayman Islands Central African Republic Chad Chile China Christmas Island Cocos (Keeling) Islands Colombia Comoros Congo Cook Islands Costa Rica Cote d'Ivoire Croatia Cuba Cyprus Czech Republic Democratic Republic of the Congo Denmark Djibouti Dominica Dominican Republic Ecuador Egypt El Salvador Equatorial Guinea Eritrea Estonia Ethiopia Falkland Islands Faroe Islands Federated States of Micronesia Fiji Finland France French Guiana French Polynesia French Southern Territories Gabon Georgia Germany Ghana Gibraltar Greece Greenland Grenada Guadeloupe Guam Guatemala Guernsey Guinea Guinea-Bissau Guyana Haiti Heard Island and Mcdonald Islands Holy See (Vatican City State) Honduras Hong Kong Hungary Iceland India Indonesia Iran Iraq Ireland Israel Italy Jamaica Japan Jersey Jordan Kazakhstan Kenya Kiribati Kosovo (Serbia and Montenegro) Kuwait Kyrgyzstan Lao People's Democratic Republic Latvia Lebanon Lesotho Liberia Libya Liechtenstein Lithuania Luxembourg Macao Madagascar Malawi Malaysia Maldives Mali Malta Marshall Islands Martinique Mauritania Mauritius Mayotte Mexico Minor Outlying Islands of the United States Moldova Monaco Mongolia Montenegro Montserrat Morocco Mozambique Myanmar Namibia Nauru Nepal Netherlands Antilles New Caledonia New Zealand Nicaragua Niger Nigeria Niue Norfolk Island North Korea North Macedonia Northern Mariana Islands Norway Oman Pakistan Palau Palestinian Territory Panama Papua New Guinea Paraguay Peru Philippines Pitcairn Poland Portugal Puerto Rico Qatar Reunion Romania Russian Federation Rwanda Saint Helena Saint Kitts and Nevis Saint Lucia Saint Pierre and Miquelon Saint Vincent and the Grenadines Samoa San Marino Sao Tome and Principe Saudi Arabia Senegal Serbia Seychelles Sierra Leone Singapore Slovakia Slovenia Solomon Islands Somalia South Africa South Georgia and the South Sandwich Is South Korea South Sudan Spain Sri Lanka Sudan Suriname Svalbard and Jan Mayen Swaziland Sweden Switzerland Syria Taiwan Tajikistan Tanzania Thailand The Gambia The Netherlands Timor-Leste Togo Tokelau Tonga Trinidad and Tobago Tunisia Turkey Turkmenistan Turks and Caicos Islands Tuvalu UK USA Uganda Ukraine United Arab Emirates United States Virgin Islands Uruguay Uzbekistan Vanuatu Venezuela Vietnam Wallis and Futuna West Bank and Gaza Strip Western Sahara Yemen Zambia Zimbabwe Please select your country/region. You must enter a comment. Competing Interests Please disclose any competing interests that might be construed to influence your judgment of the article's or peer review report's validity or importance. Competing Interests Policy Provide sufficient details of any financial or non-financial competing interests to enable users to assess whether your comments might lead a reasonable person to question your impartiality. Consider the following examples, but note that this is not an exhaustive list: Examples of 'Non-Financial Competing Interests' Within the past 4 years, you have held joint grants, published or collaborated with any of the authors of the selected paper. You have a close personal relationship (e.g. parent, spouse, sibling, or domestic partner) with any of the authors. You are a close professional associate of any of the authors (e.g. scientific mentor, recent student). You work at the same institute as any of the authors. You hope/expect to benefit (e.g. favour or employment) as a result of your submission. You are an Editor for the journal in which the article is published. Examples of 'Financial Competing Interests' You expect to receive, or in the past 4 years have received, any of the following from any commercial organisation that may gain financially from your submission: a salary, fees, funding, reimbursements. You expect to receive, or in the past 4 years have received, shared grant support or other funding with any of the authors. You hold, or are currently applying for, any patents or significant stocks/shares relating to the subject matter of the paper you are commenting on. Please state your competing interests The comment has been saved. An error has occurred. Please try again. Cancel Post var lTitle = "Med-ImageTools: An open-source Python package...".replace("'", ''); var linkedInUrl = "http://www.linkedin.com/shareArticle?url=https://f1000research.com/articles/12-118/v3" + "&title=" + encodeURIComponent(lTitle) + "&summary=" + encodeURIComponent('Read the article by '); var deliciousUrl = "https://del.icio.us/post?url=https://f1000research.com/articles/12-118/v3&title=" + encodeURIComponent(lTitle); var redditUrl = "http://reddit.com/submit?url=https://f1000research.com/articles/12-118/v3" + "&title=" + encodeURIComponent(lTitle); linkedInUrl += encodeURIComponent('Kim S et al.'); var offsetTop = /chrome/i.test( navigator.userAgent ) ? 4 : -10; var addthis_config = { ui_offset_top: offsetTop, services_compact : "facebook,twitter,www.linkedin.com,www.mendeley.com,reddit.com", services_expanded : "facebook,twitter,www.linkedin.com,www.mendeley.com,reddit.com", services_custom : [ { name: "LinkedIn", url: linkedInUrl, icon:"/img/icon/at_linkedin.svg" }, { name: "Mendeley", url: "http://www.mendeley.com/import/?url=https://f1000research.com/articles/12-118/v3/mendeley", icon:"/img/icon/at_mendeley.svg" }, { name: "Reddit", url: redditUrl, icon:"/img/icon/at_reddit.svg" }, ] }; var addthis_share = { url: "https://f1000research.com/articles/12-118", templates : { twitter : "Med-ImageTools: An open-source Python package for robust data.... Kim S et al., published by " + "@F1000Research" + ", https://f1000research.com/articles/12-118/v3" } }; if (typeof(addthis) != "undefined"){ addthis.addEventListener('addthis.ready', checkCount); addthis.addEventListener('addthis.menu.share', checkCount); } $(".f1r-shares-twitter").attr("href", "https://twitter.com/intent/tweet?text=" + addthis_share.templates.twitter); $(".f1r-shares-facebook").attr("href", "https://www.facebook.com/sharer/sharer.php?u=" + addthis_share.url); $(".f1r-shares-linkedin").attr("href", addthis_config.services_custom[0].url); $(".f1r-shares-reddit").attr("href", addthis_config.services_custom[2].url); $(".f1r-shares-mendelay").attr("href", addthis_config.services_custom[1].url); function checkCount(){ setTimeout(function(){ $(".addthis_button_expanded").each(function(){ var count = $(this).text(); if (count !== "" && count != "0") $(this).removeClass("is-hidden"); else $(this).addClass("is-hidden"); }); }, 1000); } close How to cite this report {{reportCitation}} Cancel Copy Citation Details $(function(){R.ui.buttonDropdowns('.dropdown-for-downloads');}); $(function(){R.ui.toolbarDropdowns('.toolbar-dropdown-for-downloads');}); $.get("/articles/acj/127142/177718") new F1000.Clipboard(); new F1000.ThesaurusTermsDisplay("articles", "article", "177718"); $(document).ready(function() { $( "#frame1" ).on('load', function() { var mydiv = $(this).contents().find("div"); var h = mydiv.height(); console.log(h) }); var tooltipLivingFigure = jQuery(".interactive-living-figure-label .icon-more-info"), titleLivingFigure = tooltipLivingFigure.attr("title"); tooltipLivingFigure.simpletip({ fixed: true, position: ["-115", "30"], baseClass: 'small-tooltip', content:titleLivingFigure + " " }); tooltipLivingFigure.removeAttr("title"); $("body").on("click", ".cite-living-figure", function(e) { e.preventDefault(); var ref = $(this).attr("data-ref"); $(this).closest(".living-figure-list-container").find("#" + ref).fadeIn(200); }); $("body").on("click", ".close-cite-living-figure", function(e) { e.preventDefault(); $(this).closest(".popup-window-wrapper").fadeOut(200); }); $(document).on("mouseup", function(e) { var metricsContainer = $(".article-metrics-popover-wrapper"); if (!metricsContainer.is(e.target) && metricsContainer.has(e.target).length === 0) { $(".article-metrics-close-button").click(); } }); var articleId = $('#articleId').val(); if($("#main-article-count-box").attachArticleMetrics) { $("#main-article-count-box").attachArticleMetrics(articleId, { articleMetricsView: true }); } }); var figshareWidget = $(".new_figshare_widget"); if (figshareWidget.length > 0) { window.figshare.load("f1000", function(Widget) { // Select a tag/tags defined in your page. In this tag we will place the widget. _.map(figshareWidget, function(el){ var widget = new Widget({ articleId: $(el).attr("figshare_articleId") //height:300 // this is the height of the viewer part. [Default: 550] }); widget.initialize(); // initialize the widget widget.mount(el); // mount it in a tag that's on your page // this will save the widget on the global scope for later use from // your JS scripts. This line is optional. //window.widget = widget; }); }); } close Error Close Add Reset F1000.MICROSERVICES.AFFILIATION = ''; $(document).ready(function () { $('.js-affiliations-form').each((index, form) => { new AffiliationForm({ formId: form.id, institutionErrorSelector: '.comment-enter-institution', departmentErrorSelector: '.comment-enter-department', placeSelector: '.js-add-comment-place', stateSelector: '.js-add-comment-state', zipCodeSelector: '.js-add-comment-zipcode', countrySelector: '.js-add-comment-country', countryErrorSelector: '.comment-enter-country', }); }); }); $(document).ready(function () { var reportIds = { "274816": 39, "170903": 0, "177050": 0, "207003": 0, "162202": 0, "365085": 0, "177051": 0, "207002": 0, "162203": 0, "177048": 0, "170904": 0, "207001": 0, "162200": 0, "177049": 0, "170905": 0, "207000": 0, "162201": 0, "365086": 0, "163870": 0, "177054": 0, "207007": 0, "177055": 0, "163871": 0, "207006": 0, "177052": 0, "162204": 0, "207005": 0, "207004": 0, "177053": 0, "207010": 0, "177056": 0, "366375": 11, "177057": 0, "207008": 0, "202031": 0, "202035": 0, "202034": 0, "202033": 0, "202032": 0, "202039": 0, "202038": 0, "202037": 0, "202036": 0, "170169": 0, "202040": 0, "188995": 0, "189002": 0, "189006": 0, "189009": 0, "189015": 52, "189018": 0, "189022": 0, "189026": 0, "189033": 0, "189038": 34, "274815": 19, }; $(".referee-response-container,.js-referee-report").each(function(index, el) { var reportId = $(el).attr("data-reportid"), reportCount = reportIds[reportId] || 0; $(el).find(".comments-count-container,.js-referee-report-views").html(reportCount); }); var uuidInput = $("#article_uuid"), oldUUId = uuidInput.val(), newUUId = "d11b9b05-c731-4ee6-be9e-c957f54bec58"; uuidInput.val(newUUId); $("a[href*='article_uuid=']").each(function(index, el) { var newHref = $(el).attr("href").replace(oldUUId, newUUId); $(el).attr("href", newHref); }); }); An innovative open access publishing platform offering rapid publication and open peer review, whilst supporting data deposition and sharing. Browse Gateways Collections How it Works Contact For Developers Cookie Notice Privacy Notice RSS Submit Your Research Follow us © 2012-2026 F1000 Research Ltd. ISSN 2046-1402 | Legal | Partner of Research4Life • CrossRef • ORCID • FAIRSharing R.templateTests.simpleTemplate = R.template(' $text $text $text $text $text '); R.templateTests.runTests(); var F1000platform = new F1000.Platform({ name: "f1000research", displayName: "F1000Research", hostName: "f1000research.com", id: "1", editorialEmail: "[email protected]", infoEmail: "[email protected]", usePmcStats: true }); $(function(){R.ui.dropdowns('.dropdown-for-authors, .dropdown-for-about, .dropdown-for-myresearch');}); // $(function(){R.ui.dropdowns('.dropdown-for-referees');}); $(document).ready(function () { if ($(".cookie-warning").is(":visible")) { $(".sticky").css("margin-bottom", "35px"); $(".devices").addClass("devices-and-cookie-warning"); } $(".cookie-warning .close-button").click(function (e) { $(".devices").removeClass("devices-and-cookie-warning"); $(".sticky").css("margin-bottom", "0"); }); $("#tweeter-feed .tweet-message").each(function (i, message) { var self = $(message); self.html(linkify(self.html())); }); $(".partner").on("mouseenter mouseleave", function() { $(this).find(".gray-scale, .colour").toggleClass("is-hidden"); }); }); Sign In Remember me Forgotten your password? Sign In Cancel Email or password not correct. Please try again Please wait... $(function(){ // Note: All the setup needs to run against a name attribute and *not* the id due the clonish // nature of facebox... $("a[id=googleSignInButton]").click(function(event){ event.preventDefault(); $("input[id=oAuthSystem]").val("GOOGLE"); $("form[id=oAuthForm]").submit(); }); $("a[id=facebookSignInButton]").click(function(event){ event.preventDefault(); $("input[id=oAuthSystem]").val("FACEBOOK"); $("form[id=oAuthForm]").submit(); }); $("a[id=orcidSignInButton]").click(function(event){ event.preventDefault(); $("input[id=oAuthSystem]").val("ORCID"); $("form[id=oAuthForm]").submit(); }); }); If you've forgotten your password, please enter your email address below and we'll send you instructions on how to reset your password. The email address should be the one you originally registered with F1000. Email address not valid, please try again You registered with F1000 via Google, so we cannot reset your password. To sign in, please click here . If you still need help with your Google account password, please click here . You registered with F1000 via Facebook, so we cannot reset your password. To sign in, please click here . If you still need help with your Facebook account password, please click here . Code not correct, please try again Reset password Cancel Email us for further assistance. Server error, please try again. If your email address is registered with us, we will email you instructions to reset your password. If you think you should have received this email but it has not arrived, please check your spam filters and/or contact for further assistance. Please wait... Register $(document).ready(function () { signIn.createSignInAsRow($("#sign-in-form-gfb-popup")); $(".target-field").each(function () { var uris = $(this).val().split("/"); if (uris.pop() === "login") { $(this).val(uris.toString().replace(",","/")); } }); });