Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Anders Gustafsson
    @anders9ustafsson
    I am definitely in favor of splitting the library into smaller chunks. You have my vote, Chris.
    Ian Yates
    @IanYates
    Splitting the library into smaller components, with the possibility of replacing some at runtime, would be great. Logging would be a definite candidate here (I've switched to using Serilog rather than NLog). Similarly, as @GMZ said, parsing DICOM, image manipulation, networking, etc are all related but can be separate. Not every project needs all of them. Is it a concern to keep in mind binary compatibility, or at least source compatibility, for upgraders? Or are we OK with breaking changes that might require some namespace fixes (at the least), etc?
    Hesham Desouky
    @hdesouky
    I sent an email to Colby 5 days ago to add me as an owner to nuget package of fo-dicom but no reply yet
    Ian Yates
    @IanYates
    @hdesouky - Any reply from Colby?
    Hesham Desouky
    @hdesouky
    Hello all, it has been more than 2 weeks since i sent an email to Colby with no reply. I don't know if the email went to Spam folder or he opt-out not answering my request. What is your suggestions?
    Jussi Mattila
    @jussimattila
    He is probably still reading https://groups.google.com/forum/#!forum/fo-dicom. Maybe you could try contacting him there by replying to one of his threads?
    Nicholas P Nelson
    @npnelson
    Smaller chunks are definitely needed. I have been playing with VS2015 and trying to build apps on the CoreCLR which does not include any UI stuff. Also - async/await support is desperately needed since it appears that the old Begin/End IAsyncResult pattern is being deprecated. I am trying to refactor CFIND into async/await (I might even try Reactive Extensions), but I'm not sure if I am smart enough to pull it off. Thanks for everyone's work, I will try to chip in what little I can.
    Hesham Desouky
    @hdesouky
    It was silent here for a while, any suggestions regarding the nuget package?
    Hesham Desouky
    @hdesouky
    @hiscodeness i already posted a week ago and same silent result
    Ian Yates
    @IanYates

    I can see two choices...
    1: Ask someone at NuGet.org to assign package rights. That could be a dead end, or, if NuGet agreed to do it, possibly annoy Colby (not sure if that's a concern of the new leads - I wasn't around fo-DICOM much before Colby shut up shop so I have nothing to go by to form an opinion).

    2: Pick a new name and just run with it. That'll make introducing (sensible) breaking changes easier up front too as there won't be quite the same level of expectation regarding backwards compatibility.

    @npnelson - async/await would be neat.

    You probably are already aware, but there are methods on TaskFactory that make the conversion of Begin/End with IAsyncResult a bit easier. See this blog post for examples: https://www.justjuzzy.com/2012/10/turn-iasyncresult-code-into-await-keyword/

    RX is an awesome (!!) library, but it's more for streams of data rather than one-off completions like the Begin/End method pairs. Having said that, RX also has factory methods to covert the Begin/End method pair to an Observable, which could then go to a task - if you like the scenic route :)

    Chris Horn
    @GMZ
    I’d ask what the goal here is? I’m not sure nugget is the be all and end all. personly I think that nuget is more noise than signal. It’s absolutly litterd with incomplete, and abandoned projects, more than half of the things I get from nuget I end getting the source for to fix errors,
    maybe we should spend time addressing issues/ changes and and worry about distribution once it’s reached a quality marker.
    or as Ian suggests pick a new name and start a new project, group and nugget package...
    Hesham Desouky
    @hdesouky
    GMZ, in that case let us agree to the main repo where all pull requests can be gathered
    @GMZ can you volunteer you repo as the main one?
    Ian Yates
    @IanYates
    There have been a couple of questions in the mailing list about the source. Settling on a repo makes sense. I don't mind which one, although perhaps it should be then be forked into its own org/repo which becomes the ongoing canonical repo.
    Anders Gustafsson
    @anders9ustafsson
    I just checked. If we want to keep the fo-dicom name, it is currently possible to register an organization named "fo-dicom" on Github .
    Hesham Desouky
    @hdesouky
    To bring some motion here, i will create the org and push my latest changes there
    Anders Gustafsson
    @anders9ustafsson
    Great! Thanks.
    Ian Yates
    @IanYates
    Awesome :) \
    (typo on the )
    \ )
    Hesham Desouky
    @hdesouky
    @anders9ustafsson @IanYates @GMZ organization created
    repository forked
    invitations sent
    We need to go with important things first
    all sever issues fixes should be pushed to the new main repository
    After doing so, a new post should be submitted to the group now to indicate the new repository/organization locations
    waiting your input :smile:
    Ian Yates
    @IanYates
    Excellent news @hdesouky - I've accepted the GitHub invitation (and thanks for inviting me too!)
    Anders Gustafsson
    @anders9ustafsson
    This is great, Hesham. Thanks for inviting me. You have copied your own repository, right? Just as a refresher, could you briefly summarize the differences between your fork and the most recent commit from Colby?
    And one other thing: we might just as well move the discussion over to gitter.im/fo-dicom/fo-dicom now that we have a dedicated repository for future development. Or what do you think?
    Ian Yates
    @IanYates
    @anders9ustafsson - Makes sense.
    Rickard Holmberg
    @rickardraysearch
    Did you move the discussion? I'm getting a 404 on http://gitter.im/fo-dicom/fo-dicom , so I assume that I'm not authorized (per github's strange interpretation of http status codes... ;-)
    Anders Gustafsson
    @anders9ustafsson
    @rickardraysearch No, the discussion hasn't moved, at least not yet. BTW, can you access the new repository at https://github.com/fo-dicom/fo-dicom ? I am unsure how publicly visible that repository is at the moment.
    Rickard Holmberg
    @rickardraysearch
    Hi @anders9ustafsson ! Yes, the https://github.com/fo-dicom/fo-dicom repo seems to be completely public - at least I can see it even when not logged in to github.

    Btw, regarding the name of the project: are we ignoring Colby's plead

    (And please, please think of a name better than Fellow Oak DICOM for .NET!)

    from the End of the road posting? ;-) I like the current name, but it also seems like a quite reasonable request from him...

    Hesham Desouky
    @hdesouky
    We already go through this discussion and aged to go with the current name for the time being until we bring the project back to life
    Anders Gustafsson
    @anders9ustafsson
    I have now been so bold and created a Gitter chat room for the new fo-dicom repository, here. As far as I have been able, I have invited those people already listed in this chat room to the new chat. If anyone is not OK with this change, please let me know. Otherwise, I suggest that continued fo-dicom discussion is held in the new chat room.
    Hesham Desouky
    @hdesouky
    Nice idea
    Chris Horn
    @GMZ
    well done
    Michael Pavlovsky
    @michaelp
    @/all I am looking for real life business story that would be able to utilize fo-dicom imaging. In other words a real user (not a software guy) that would use fo-dicom imaging in his business. I have a lot of ideas what would it be, but i always prefer to talk to a real customer first.
    Aerik Sylvan
    @aerik
    @michaelp We are using Fo-Dicom to drive a web viewer that we are just rolling out to a number of customers who are very happy to not have to install client software. I cannot refer you to any real customers and am probably constrained about business details, but can discuss general info probably...
    Michael Pavlovsky
    @michaelp
    This message was deleted
    Helder Pinhal
    @HelderMPinhal

    @michaelp Hi. I am a developer as well but currently have a couple of products already installed and being used.
    I have a software to acquire the video signal from non-dicom ultrasound devices and generating/rendering dicom files to be stored in a PACS.
    Another software, not related to image rendering, is a worklist. Both working perfectly fine.

    Since you guys have been talking about fo-dicom in another operative systems, I have been considering an Android viewer, if Android will be an option of course.

    Michael Pavlovsky
    @michaelp
    @aerik i assume that are talking about vet rocket dicom viewer. I also assume that it is 2d viewer with some annotations , and the modality is X ray or ultra sound. Could you please ping me in private, i would like to chat with you about "how would ideal imaging toolkit would look like for your application"
    Michael Pavlovsky
    @michaelp
    @HelderMPinhal do you expect to use android device for clinical examination? What kind of work flows you would support?
    Aerik Sylvan
    @aerik
    @michaelp huh. Did I leave it laying around in a public repository or something, or did you see it at a show? Ill ping you.
    Phong Bui
    @loveunCG
    @loveunCG
    hello
    everybody
    I gona build 3dDicom viewer using unity3d
    and this fodicom lib
    I wana start this right now