Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Libisyntax integration #437

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

alex-virodov
Copy link

This PR enables support of the .isyntax WSI format using amspath/libisyntax.

I am still using a submodule to include libisyntax, so please do git submodule update --init after checking out the PR branch.

Tested with:

~/openslide-isyntax-integration/builddir$ ./tools/openslide-write-png /home/user/openslide/testslide.isyntax 0 0 5 1000 1000 /home/user/openslide/output.png

Test slide used is from OpenPhi project (MIT license): https://zenodo.org/record/5037046/#.ZAn17IDMLJU

Signed-off-by: Alexandr Virodov <alexandr.virodov@uky.edu>
… C api.

Signed-off-by: Alexandr Virodov <alexandr.virodov@uky.edu>
@github-actions
Copy link

github-actions bot commented Apr 21, 2023

DCO signed off ✔️

All commits have been signed off. You have certified to the terms of the Developer Certificate of Origin, version 1.1. In particular, you certify that this contribution has not been developed using information obtained under a non-disclosure agreement or other license terms that forbid you from contributing it under the GNU Lesser General Public License, version 2.1.

Copy link
Member

@bgilbert bgilbert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great, thanks for the PR! There's been an open RFE #145 for iSyntax support since 2014, and I'm looking forward to getting this in.

@@ -0,0 +1,3 @@
[submodule "src/libisyntax"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the record, we'll want to switch to a Meson wrap before this lands.

src/openslide-vendor-philips-isyntax.c Outdated Show resolved Hide resolved
src/meson.build Show resolved Hide resolved
src/openslide-private.h Show resolved Hide resolved
src/openslide-vendor-philips-isyntax.c Outdated Show resolved Hide resolved
src/openslide-vendor-philips-isyntax.c Outdated Show resolved Hide resolved
LOG_VAR("%d", (int)open_result);
// LOG_VAR("%d", data->isyntax->image_count); // TODO(avirodov): getter.
if (open_result != LIBISYNTAX_OK) {
free(data);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will cause a double free in openslide_close(), since we've already attached data to the openslide_t. Generally we don't attach anything to the openslide_t until we know the open will succeed.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done I think, please take a look at the flow again if you don't mind. Will keep open.

src/openslide-vendor-philips-isyntax.c Outdated Show resolved Hide resolved
src/openslide-vendor-philips-isyntax.c Outdated Show resolved Hide resolved
philips_isyntax_t* data = malloc(sizeof(philips_isyntax_t));

osr->data = data;
isyntax_error_t open_result = libisyntax_open(filename, /*is_init_allocators=*/0, &data->isyntax);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should use the OpenSlide VFS, rather than having libisyntax do its own I/O.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, but this will take a while to implement in libisyntax. Is this a requirement for Meson work/PR submission? If so, please let me know so I can prioritize.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not a prerequisite for Meson work, or for work to proceed on this PR. Ideally the PR wouldn't merge before VFS support is available, but I'd consider leaving VFS support to a followup PR if it's impractical to do at present. Eventually the test suite will be refactored in a way that will require the VFS, but that hasn't happened yet.

&cache_entry);
if (!tiledata) {
int scale = libisyntax_level_get_scale(pi_level->isyntax_level);
ASSERT_OK(libisyntax_tile_read(isyntax, data->cache->cache, scale, tile_col, tile_row, &tiledata));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the current libisyntax implementation, we need to byteswap the result on big-endian systems. (Neither libisyntax nor OpenSlide are currently being tested on such systems, though, so it's possible that there are more fundamental issues as well.)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there anything actionable I can do here? Just checking. Please unresolve if there is.

Maybe it will be somewhat addressed by having an output_format=RGBA or BGRA flag that we are discussing in libisyntax thread. That flag could include endianness later on (e.g. ABGR if needed).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eventually big-endian systems should be handled either in libisyntax or here. libisyntax is probably the correct place for it, so hopefully OpenSlide won't have to do anything. I'll unresolve until we have a solid answer here.

I've acquired access to a s390x machine for big-endian testing. I can help run tests when this work gets further along.

…ers on separate lines.

Signed-off-by: Alexandr Virodov <alexandr.virodov@uky.edu>
Signed-off-by: Alexandr Virodov <alexandr.virodov@uky.edu>
@alex-virodov
Copy link
Author

Thank you for the review. I addressed the more editorial comments, I will continue with the logic-affecting ones next.

Signed-off-by: Alexandr Virodov <alexandr.virodov@uky.edu>
Signed-off-by: Alexandr Virodov <alexandr.virodov@uky.edu>
Signed-off-by: Alexandr Virodov <alexandr.virodov@uky.edu>
@alex-virodov
Copy link
Author

@bgilbert I believe I addressed all the comments. Please take a look again when you have a chance.

Signed-off-by: Alexandr Virodov <alexandr.virodov@uky.edu>
Signed-off-by: Alexandr Virodov <alexandr.virodov@uky.edu>
Signed-off-by: Alexandr Virodov <alexandr.virodov@uky.edu>
Signed-off-by: Alexandr Virodov <alexandr.virodov@uky.edu>
@bgilbert
Copy link
Member

Thanks for the updates! I'll circle back to this when I can.

@Nathan-Thompson
Copy link

Hey @bgilbert @alex-virodov! Is there anything I can do to help move this PR forward? Thanks!

@bgilbert
Copy link
Member

I still very much want to get back to this. Unfortunately, I won't be able to until at least September, but I'm hoping to dedicate some time to it then.

@alex-virodov
Copy link
Author

TLDR: I'm no longer working on this, but I would be happy to answer questions and helping it get done.

Hello. We originally discussed this PR to be a proof of concept, and a proper integration would involve a separate libisyntax linux package. Since I am no longer working on this project, I won't be able to make that happen. Maybe @Falcury would want to pick that part up. Or @bgilbert approves and we add libisyntax as source/submodule (though this has downsides). Or any other acceptable short path to get it in (I listed the ones we discussed).

But in any case I don't think this PR will go in as-is. It currently uses libisyntax as a git submodule, and keeping it that way may need changes from the build system. Also some comments remain unaddressed (e.g. metadata implementation is missing), so there's some more work to be done, or to be deferred.

@bgilbert
Copy link
Member

@alex-virodov Thanks for the update, and for your work on this! If @Falcury would like to take over this PR, he's welcome to of course, and otherwise I can plan to work on it myself. I'm still planning to get Meson support into libisyntax so we can wrap it here as a subproject (pending distro packages), similar to what we're doing with libdicom.

I appreciate everyone's patience with the longer review cycle on this one. The DICOM work and release stabilization had to take priority unfortunately.

@Falcury
Copy link

Falcury commented Oct 8, 2023

I could give it a go to pick this up, however my time available to work on this PR (and libisyntax) wil be very limited until early next year. In any case, when I have time I will try to address some of the to-do items.

@bgilbert
Copy link
Member

Initial libisyntax Meson port in amspath/libisyntax#40.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants