Hi Steffi,<div><br></div><div>> I do not see why <? extends RealType> would have any advantage.</div><div><br></div><div>Here is an example of a practical difference between the two constructs:</div><div><br></div>
<div><div> ImgOpener imgOpener = new ImgOpener();</div><div> ImgPlus<? extends RealType> img = imgOpener.openImg("/Users/curtis/data/toucan.png");</div><div> ImgPlus<RealType> realImg = (ImgPlus<RealType>) img;</div>
<div> ImgPlus<UnsignedByteType> ubyteImg = (ImgPlus<UnsignedByteType>) img; // this works</div><div> ImgPlus<UnsignedByteType> ubyteImg2 = (ImgPlus<UnsignedByteType>) realImg; // illegal</div>
<div> ImgPlus<UnsignedByteType> ubyteImg3 = (ImgPlus) realImg; // also works</div></div><div><br></div><div>In the above example, the compiler allows casting a "ImgPlus<? extends RealType>" to a "ImgPlus<UnsignedByteType>" (ubyteImg) but does not allow doing so from a "ImgPlus<RealType>" (ubyteImg2). You instead must go through a completely raw type to make it work (ubyteImg3).</div>
<div><br></div><div>I think "? extends RealType" is more correct, and also behaves better in cases such as the above. However, I agree it is more of a pain to write, so if you think the tradeoff is worth it, we can stick with ImgPlus<RealType> instead and just document why we did it in the ImgOpener javadoc.</div>
<div><br></div><div>What do you think?</div><div><br></div><div>Regards,</div><div>Curtis</div><div><br></div><div><br><div class="gmail_quote">On Tue, Jul 31, 2012 at 5:18 PM, Stephan Preibisch <span dir="ltr"><<a href="mailto:preibisch@mpi-cbg.de" target="_blank">preibisch@mpi-cbg.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Barry, hi Curtis,<div><br></div><div>the example you give would give you a warning, and, yes, - a runtime error. The problem is, there is no right way to do it as the type is not defined at compile time but instead depends on the image that is opened. </div>
<div><br></div><div>However, I do not see why <? extends RealType> would have any advantage. It crashes on the exactly same thing, but is more tough to write, see here:</div><div><br></div><div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal normal normal 11px/normal Monaco;color:rgb(65,58,246)">
<span style="color:#000000">Img< </span><span style="color:rgb(0,0,0)">RealType</span><span style="color:#000000"> ></span><span style="color:rgb(0,0,0)">img</span><span style="color:#000000"> = ImgOpener.open( </span>"/Users/preibischs/Documents/Microscopy/SPIM/HisYFP-SPIM/spim_TL18_Angle0.lsm"<span style="color:#000000"> );</span></div>
</div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal normal normal 11px/normal Monaco;color:rgb(65,58,246)"><span style="color:#000000"><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal normal normal 11px/normal Monaco">
img.firstElement().add( <span style="color:rgb(151,25,101)">new</span> FloatType() );</div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal normal normal 11px/normal Monaco"><br></div>
<div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal normal normal 11px/normal Monaco">-> fails because cannot cast to ByteType (what the image is)</div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal normal normal 11px/normal Monaco">
<br></div></span><span style="color:rgb(0,0,0)"><div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal normal normal 11px/normal Monaco;color:rgb(65,58,246)"><span style="color:rgb(0,0,0)">Img< ? extends </span><span style="color:rgb(0,0,0)">RealType</span><span style="color:rgb(0,0,0)"> ></span><span style="color:rgb(0,0,0)">img</span><span style="color:rgb(0,0,0)"> = ImgOpener.open( </span>"/Users/preibischs/Documents/Microscopy/SPIM/HisYFP-SPIM/spim_TL18_Angle0.lsm"<span style="color:rgb(0,0,0)"> );</span></div>
</div><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal normal normal 11px/normal Monaco;color:rgb(65,58,246)"><span style="color:rgb(0,0,0)"><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal normal normal 11px/normal Monaco">
img.firstElement().add( <span style="color:rgb(151,25,101)">new</span> FloatType() );</div><div><br></div><div>-> fails as well, but is more to write</div><div><br></div></span></div></span></div><div>And the construct <? extends RealType<?>> would be correct but cannot be used in any generic method as it is not ensured that the first and the second "?" are the same. </div>
<div><br></div><div>We still have to choose one of them, I still vote for Img< RealType >, because it is at least easy to write.</div><div><br></div><div>The best is to open it as FloatType or as ByteType, but this is not always possible ...</div>
<div><br></div><div>What do you think? </div><div><br></div><div>Bye bye,</div><div>Steffi</div><div><div class="h5"><div><br></div><div><br></div><div><div><div>On Jul 31, 2012, at 17:59 , Curtis Rueden wrote:</div><br>
<blockquote type="cite">
Hi Barry,<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>This is just an example I've pulled from the web but it seems to imply that an Img<UnsignedByteType> is not safely considered an Img<RealType>.</blockquote>
<div><br></div><div>Good point! We should probably use "Img<? extends RealType>" instead. I tested this with ImageJ2, and it still works as expected. And I believe all of Steffi's example cases will still work too. So I pushed these changes to the newimgopener branch.</div>
<div><br></div><div>What do you think, Steffi? Anyone else?</div><div><br></div><div>Regards,</div><div>Curtis</div><div><br></div><div><br></div><div class="gmail_quote">On Tue, Jul 31, 2012 at 4:28 PM, Barry DeZonia <span dir="ltr"><<a href="mailto:bdezonia@gmail.com" target="_blank">bdezonia@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Steffi,<div><br></div><div>I remember running into this when originally interfacing IJ2 to Imglib. We did decided to go with Img<? extends RealType<?> as that seemed the most safe at the time.</div>
<div><br></div>
<div>What I'm wondering about with your solution is that it seems to contradict other people's description as to what is legal to do in Java.</div><div><br></div><div>As a contrived example think of the animal cage example:</div>
<div><br></div><div>We have a Animal class and a Lion class derived from it. And a Cage class that is defined Cage<T extends Animal>.</div><div><br></div><div>Though Lion is instanceof Animal its not the case that Cage<Lion> instanceof Cage<Animal>. This is counterintuitive but many people mention it.</div>
<div><br></div><div>If it was the case you could write code like this:</div><div><br></div><div><pre style="margin-top:0px;margin-bottom:10px;padding:5px;border:0px;font-size:14px;vertical-align:baseline;background-color:rgb(238,238,238);font-family:Consolas,Menlo,Monaco,'Lucida Console','Liberation Mono','DejaVu Sans Mono','Bitstream Vera Sans Mono','Courier New',monospace,serif;overflow:auto;width:auto;max-height:600px;line-height:18px;text-align:left">
<code style="margin:0px;padding:0px;border:0px;vertical-align:baseline;font-family:Consolas,Menlo,Monaco,'Lucida Console','Liberation Mono','DejaVu Sans Mono','Bitstream Vera Sans Mono','Courier New',monospace,serif"><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent;color:rgb(43,145,175)">Cage</span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent"><</span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent;color:rgb(43,145,175)">Animal</span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent">></span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent"> animals</span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent">;</span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent"><br>
</span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent;color:rgb(43,145,175)">Cage</span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent"><</span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent;color:rgb(43,145,175)">Lion</span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent">></span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent"> lions</span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent">;</span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent"><br>
animals </span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent">=</span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent"> lions</span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent">;</span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent"> </span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent;color:gray">// This assignment is not allowed</span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent"><br>
animals</span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent">.</span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent">add</span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent">(</span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent">rat</span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent">);</span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent"> </span><span style="margin:0px;padding:0px;border:0px;vertical-align:baseline;background-color:transparent;color:gray">// If this executed, we'd have a Rat in a Cage<Lion></span></code></pre>
<div><br></div>This is just an example I've pulled from the web but it seems to imply that an Img<UnsignedByteType> is not safely considered an Img<RealType>. We may be avoiding all such cases where it could be a problem but is it safe going forward? I can't say I know.</div>
<div><br></div><div><br><div class="gmail_quote"><div>On Tue, Jul 17, 2012 at 4:08 PM, Stephan Preibisch <span dir="ltr"><<a href="mailto:preibisch@mpi-cbg.de" target="_blank">preibisch@mpi-cbg.de</a>></span> wrote:<br>
</div><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi guys,<br>
<br>
this became a massive explanation. I suggest this as as solution to a problem we have been only partly aware of. I hope you enjoy reading ;)<br>
<br>
Steffi<br>
<br>
<br>
As the ImageJ conference is approaching I was talking with Johannes and we agreed that the ImgOpener needs to be finished. However, since its first version there has been a major design fault.<br>
<br>
But first the good news:<br>
--------------------------------<br>
It works perfectly fine if you say "open me an Image as float" or "...as UnsignedByte" or whatever, classically called by the method<br>
-> new ImgOpener.openImg( String id, ImgFactory<T> factory, T type );<br>
It can, without any problems, return you an Img<T>, and it requires that T is RealType (and not anymore NativeType, see at the end). So far, so good.<br>
Note that "T" is NOT a return parameter, but something you give to the openAs method.<br>
<br>
Now the bad news.<br>
--------------------------<br>
If you say "open this image as whatever RealType it is", it can do that, but it cannot assign a "T" to it - because T is not a return parameter. We made an ugly hack inside so that it seems as if it would work, but it does not. Now you might ask, why change it if it worked so far? Well, here is an easy example that would cause a ClassCastException on run time<br>
<br>
public static <T extends RealType< T >> void main( String[] args )<br>
{<br>
Img< T > img1 = new ImgOpener.openImg( "somepic_8bit.tif" ); // 8-bit unsigned<br>
Img< T > img2 = new ImgOpener.openImg( "somepic_32bit.tif" ); // 32-bit float<br>
<br>
img1.firstElement().set( img2.firstElement() ); // run-time crash<br>
}<br>
<br>
It will throw a ClassCastException because img1 is of UnsignedByteType and img2 of FloatType. But as we cast it in a dirty way, it compiles just fine.<br>
So, we cannot return a "T", but what we can return is Img< which is at least a RealType >. And this is for sure always true, but img1 and img2 are not necessarily the same RealType (as above).<br>
<br>
The correct way (which doesn't work)<br>
--------------------------------------------------<br>
What we should return is an Img< ? extends RealType< ? > >. However, it is not ensured that the two "?" are the same, so an Img of this type is basically incompatible with everything else, which means an unchecked cast is necessary. So although correct, maybe not a good idea. And it is really ugly to write if necessary.<br>
<br>
The still somehow correct way<br>
-----------------------------------------<br>
Instead, it returns now an Img< RealType >. This is kind of a tradeoff. On one hand, this is very easy to write and will give you compile errors where it should, for example<br>
<br>
img1.firstElement().set( img2.firstElement() ); // COMPILE ERROR (not the same RealType realization)<br>
<br>
OR<br>
<br>
public <T extends RealType< T >> void add( IterableInterval< T > i1, IterableInterval< T > i2 ) { .... }<br>
add( img1, img2 ); // COMPILE ERROR (not the same RealType realization)<br>
<br>
BUT<br>
<br>
Gauss.inFloatInPlace( 2.0 , img1 ); // FINE (just one RealType realization required, inside it will be always the same "T")<br>
Gauss.inFloatInPlace( 2.0 , img2 ); // FINE (just one RealType realization required, inside it will be always the same "T")<br>
<br>
public < T extends RealType< T > > void add1( Img< T > img1, double value ) { ... }<br>
add1( img1, 5 ); // FINE (just one RealType realization required, inside it will be always the same "T")<br>
<br>
public < T extends RealType< T >, S extends RealType< S > > void add2( Img< T > img1, Img< S > img2 ) { ... }<br>
add2( img1, img2 ); // FINE (explicitly two different RealType realizations are allowed)<br>
<br>
public void add3( Img< RealType > img1, Img< RealType > img2 ) { ... }<br>
add3( img1, img2 ); // FINE (both are just some kind of RealType, but gives a warning)<br>
<br>
On the other hand it gives a lot of Warnings because RealType should be more specified.<br>
<br>
Why not Img< RealType< ? > ><br>
------------------------------------------<br>
Similar problem as in <? extends RealType< ? > >. RealType< ? > is not a valid substitute for any construct like < T extends RealType < T > >. One would have to cast to Img< RealType >, so we can take this one right away as it is less writing.<br>
<br>
Where did NativeType go?<br>
------------------------------------<br>
I do not see any reason why we should enforce a NativeType. There is no objection to load an image into a (hypothetical) ListImg< BigDecimalType >.<br>
<br>
What are the implications?<br>
-----------------------------------<br>
We should write NOTHING except the method opening files for Img< RealType >. And also only if it is really required - quite often it is not. But if, Img< RealType > It is a completely valid input for any generic algorithm as show above for Gauss, add, etc.<br>
<br>
<br>
<br>
I implemented the changes on a branch called 'newimgopener'. It also contains four static convenience opening methods and a speed improvement.<br>
<br>
Any comments are very welcome. If somebody has a better idea how to solve the problem ... I am all ears ...<br>
<br>
Bye bye,<br>
Steffi<br>
<span><font color="#888888"><br>
--<br>
Please avoid top-posting, and please make sure to reply-to-all!<br>
<br>
Mailing list web interface: <a href="http://groups.google.com/group/fiji-devel" target="_blank">http://groups.google.com/group/fiji-devel</a><br>
</font></span></blockquote></div></div></div><br></div><div><div><div><br></div>
-- <br>
Please avoid top-posting, and please make sure to reply-to-all!<br>
<br>
Mailing list web interface: <a href="http://groups.google.com/group/fiji-devel" target="_blank">http://groups.google.com/group/fiji-devel</a><br>
</div></div></blockquote></div><br><div><br></div>
-- <br>
Please avoid top-posting, and please make sure to reply-to-all!<br>
<br>
Mailing list web interface: <a href="http://groups.google.com/group/fiji-devel" target="_blank">http://groups.google.com/group/fiji-devel</a><br>
</blockquote></div><br></div></div></div></div><div class="HOEnZb"><div class="h5">
<p></p>
-- <br>
Please avoid top-posting, and please make sure to reply-to-all!<br>
<br>
Mailing list web interface: <a href="http://groups.google.com/group/fiji-devel" target="_blank">http://groups.google.com/group/fiji-devel</a><br>
</div></div></blockquote></div><br></div>