Zeiss ZVI file format support development for OpenSlide

Thu Jul 19 01:36:01 EDT 2012

Greetings!

Thanks for quick reply! I do appreciate that!

On 07/19/12 04:57, Benjamin Gilbert wrote:
> On 07/18/2012 03:29 AM, Alexandre Kharlamov wrote:
>> Sure, I can try libgsf if you add it (or show me how to add it)
>> to dependencies. I'm not very fluent with autoconf scripts yet.
> Sure.  The Autotools changes are in the libgsf branch of 
> <https://github.com/bgilbert/openslide>.  I have not updated CMake.
I'll take a look, but not sure what you mean by "I have not updated
CMake." Can you please explain?
>> Btw, can you please explain in detail, what functions I need to
>> add (and what files) so that bitmap files can be converted to ARGB?
> Detailed specifications are rare in open-source projects.  The typical 
> procedure for contributing a new module goes something like this:
>
> 1.  Find the smallest existing module that's similar to what you're 
> trying to do, and read it.
>
> 2.  Implement a module based on what you discover, consulting other 
> existing code as needed.
>
> 3.  As soon as you have something that barely works, post it publicly 
> for comment.  This is where you learn about all of the requirements you 
> missed and the existing code you misunderstood.
>
> 4.  Improve your code and go to step 3.
>
> Since this is an iterative process, it's important to post your code 
> early rather than waiting until it's "done".
There are many OpenSource philosophies, but isn't the sole advantage
of modularity in the fact that the maker of new module does not need
to know all the internals?
> But why can't we just write some documentation?
>
> Every non-trivial slide format (and ZVI is one of those) imposes new 
> requirements on OpenSlide which require us to modify its architecture.
Well, I'm sorry, but if architecture needs modification - it tells something
about the architecture. And until architecture is fixed I cannot proceed
with my work :-(
>  
> We can't give you a precise set of instructions for integrating with 
> OpenSlide, because OpenSlide may not provide the functionality you need! 
>   So, as you approach your changes, you should be thinking of the entire 
> library as within your purview, not just one vendor driver.  If the core 
> needs to be changed (and it will!), send patches.
Why would I want to change the core? You do realize that there are several
people hired to make one or two file formats supported each. Changing the
core requires from each of us to read all the code. We are not
paid for that extra work. Our task is to "make things work" as soon as
possible. And the employer has the right to demand that. I can't send him
reports saying "This week I'm gonna read the core code, carefully study it
and see what small change need to be made next week, subject to approval by
Benjamin, so that in two weeks we can make another small change to the
core."
And there are other people waiting. Agelos cannot do his work neither.
Right now
the project does not seem to move nowhere (correct me if I'm wrong) and
something
needs to be done about it.
>> I'm looking to use libnsbmp linked statically for loading bmp.
>> It's basically two files libnsbmp.c and libnsbmp.h
>> That library is only for reading bitmap files, and, unlike many others,
>> it supports Run-Length-Encoded bitmaps.
> We should try to select widely-used libraries whenever possible. 
> libnsbmp is not packaged on Fedora and not actively maintained on 
> Debian/Ubuntu, so the additional dependency would be problematic for 
> packagers.  And the packaging policies of various Linux distributions 
> prohibit us from building the library in our own source tree and 
> statically linking it.
I'm sorry, who can prohibit you from including a .c and a .h file in
your src
folder, compile it to a .o and link to it statically??
> I propose gdk-pixbuf.  It's in the Gtk suite of libraries that we 
> already use, and it adds no new transitive dependencies.  It also 
> appears to support RLE.
I could not find list of file formats supported by it anywhere in the
internet.
Apparently that depends on the set of modules compiled with it, but even
that info I could not find :-(
>> l propose this approach that does not require changes in API:
>> Every single image in the file gets a level id, unless it's a part of
>> mosaic.
> No.  That's a hack.
Like if changing core to make a module work isn't...
>
> ZVI support is going to require effort on several levels:
>
> 1.  The vendor driver,
> 2.  An ops backend for BMP-formatted images,
> 3.  API and backend changes to support multiple channels/timepoints.
>
> And: since the JPEG ops backend assumes that a JPEG can be represented 
> by a single filename/offset/length tuple, which is not true in ZVI, even 
> point 1 will require you to make changes to the existing backend code.
Oh, thanks a lot!
> We're not going to accomplish all of this in one step.  You should start 
> by submitting a driver that returns three-channel color in the first 
> focal plane at the first timesample.  If possible, you should support 
> only JPEG-compressed ZVIs using the JPEG backend.
>
> "But that's not useful!", you say.
>
> Code is communication.  The easier it is for me to see that your changes 
> are correct, the easier it will be for me to merge your code.  Each 
> commit should do one, defensible, thing.
So, instead of telling me HOW to do it right, you're saying: "Try what
you can, and if it's wrong I'll tell you to redo it until it's right".
Hmm...
You know, I'd be more productive working on my little Slidewalk GUI,
integrate zvi support there, and once everything is done, start proposing
changes in your API so that zvi support can be included into your code.
It'll take less time in a long run...

Thanks a lot, but to make this project viable for me, I need
to produce a lot more than what can be done with your bit-per-week
approach.
>
> After you have integrated basic support for reading ZVI files, we can 
> consider the next step.  You will then be in a better position to 
> discuss what you need from the OpenSlide external and internal APIs.
I'll talk to my employer. "Discussing what I need from the Openslide
external and internal API's" isn't really my strong side. I'd rather work on
my little bit of code, get it done and move on. Writing support for some
relatively simple file format should not be a full-time job. When I started
this project I estimated to finish it in one week. Now it is looking like
"mission impossible" to me :-(

Best regards,

-Alexandre Kharlamov
>
> --Benjamin Gilbert
> _______________________________________________
> openslide-users mailing list
> openslide-users at lists.andrew.cmu.edu
> https://lists.andrew.cmu.edu/mailman/listinfo/openslide-users