Converter
for it...
@ctrueden I'm working on some of those low hanger fruit image conversion functions in imagej-common
. When I run mvn
the ImgLabelingConversionTest
test incorrectly grabs the RAIToDatasetConverter.class
we wrote instead of ImgLabelingToImgConverter
.
Here's the output:
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] ImgLabelingConversionTest.testImgLabelingToImgConversion:81 expected:<class net.imagej.convert.ImgLabelingToImgConverter> but was:<class net.imagej.convert.RAIToDatasetConverter>
[ERROR] Errors:
[ERROR] ImgLabelingConversionTest.testTwoWayConversion:92 » IllegalArgument Only RealT...
[INFO]
[ERROR] Tests run: 293, Failures: 1, Errors: 1, Skipped: 0
Here is the line that fails in the test
assertEquals(ImgLabelingToImgConverter.class, convertService.getHandler(labeling, Img.class).getClass());
I'm guessing convertService.getHandler()
is returning the wrong class because the RAIToDatasetConverter
is vague enough that ImgLabeling
is caught. Its not obvious to me...how do I limit the scope to avoid this?
RAIToDatasetConverter
doesn't work unless the RAI in question has RealType
samples.
supports
or canConvert
method.
supports
& canConvert
method.
@Override
public boolean canConvert(final Object src, final Type dest) {
if (!hasCompatibleType(src)) return false;
return super.canConvert(src, dest);
}
@Override
public boolean canConvert(final Object src, final Class<?> dest) {
if (!hasCompatibleType(src)) return false;
return super.canConvert(src, dest);
}
hasCompatibleType(Object)
. net.imglib2.util.Util.getTypeFromInterval((RandomAccessibleInterval) src)
is your friend here.
net.imagej:ij:1.53k
through net.imagej:ij:1.53p
deployed to OSS Sonatype. Yay!1.x-SNAPSHOT
whenever it changes, which is always accessible from maven.scijava.org and should be equivalent to the latest daily build.net.imagej:ij
to OSS Sonatype automatically, so it doesn't fall behind again.Hello everyone, I'm a member of the tomancak lab now. Since one and a halve weeks now!
@ctrueden / @hinerm Could you please create a new update site https://sites.imagej.net/TomancakLab/ and give access rights to me "Maarzt" and @xulman "xulman"
setBatchMode(true)
: the output images are never created or made available to the user in a way they can be readily accessed in macro code. My guess is that the output parameter processing is not occurring, or is occurring but the data are not 'presented' in a macro accessible way. In a batch mode macro images can normally be accessed with selectImage()
, but no images are available to be selected. Macros run fine with setBatchMode(false)
.
@mdoube Thanks for the report, and sorry to hear of the trouble. I would call this a bug. Regarding whether it's "known": maybe years ago I could have said yes, there is some quirk of the IJ<->IJ2 synchronization with batch mode, but in 2022 I cannot recall, so I'll say no, it's not known. Whether it can be fixed: would need to dig to see whether it's easily fixable, or more systemic. Sorry I can't shed more light on it off the top of my head.
I tried reading the thread you linked, but it's >70 posts long and the last discussion is in Jython, which has diverged from the macro issue. I scanned the entire thread searching for setBatchMode
but couldn't find any post with that command. Is there a particular post number you can link me to that would illustrate the issue?
If you file an issue in imagej-legacy I can probably spend some time digging on Friday, May 27.