ImageJ

Java Compile Errors

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

David Webster

Java Compile Errors

I was just checking out the capability of converting a
Plugins/Macro/Record macro to a plugin, but get errors when I use
File/Compile and Run. I am Java ignorant so I don't know what gives.

My recorded macro is:

run("Duplicate...", "title=tim-1.bmp");
rename("test");
run("Mean...", "radius=2");
imageCalculator("Add create", "tim.bmp","test");
//run("Image Calculator...", "image1=tim.bmp operation=Add image2=test
create");
selectWindow("test");

The Java code is:
import ij.*;
import ij.process.*;
import ij.gui.*;
import java.awt.*;
import ij.plugin.*;

public class test2plugin_ implements PlugIn {

public void run(String arg) {
IJ.run("Duplicate...", "title=tim-1.bmp");
IJ.rename("test");
IJ.run("Mean...", "radius=2");
IJ.imageCalculator("Add create", "tim.bmp","test");
IJ.run("Image Calculator...", "image1=tim.bmp
operation=Add image2=test create");
IJ.selectWindow("test");
}

}

and the errors are:

C:\Program Files\ImageJ\plugins\test2plugin_.java:11: cannot find symbol
symbol : method rename(java.lang.String)
location: class ij.IJ
IJ.rename("test");
^
C:\Program Files\ImageJ\plugins\test2plugin_.java:13: cannot find symbol
symbol : method imageCalculator
(java.lang.String,java.lang.String,java.lang.String)
location: class ij.IJ
IJ.imageCalculator("Add create", "tim.bmp","test");
^
2 errors

I just now took an automatic update for Java (1.6.0_10 [32 bit]), could
this be the problem? Sory for being so clueless.

David Webster

Zummy

Importing URLs. Use content type or content disposition, please

We are trying to download JPEG images into ImageJ through URLs that look
like this:

http://image.llnl.gov/cmsdk/content/urn:llnl.gov:nif:archive:9991debe-47e9-4
894-9e1a-7e2febf26522

This won't load in ImageJ, we think because there isn't a file extension on
the end of the URL. We aren't sure that we can modify WebDAV to add an
extension to the end of the URL, like ?fileType=.jpg

We currently have a servlet which uses a file extension at the end of the
URL to pass to ImageJ. We use this to convert HDFs to PNG to download the
PNG into imagej. We might continue this practice, because I am not aware
that ImageJ can load an HDF 5 (H5) file.

Can ImageJ look at HTTP Content-Type and Content-Disposition headers to
determine the file type and file name/title? I guess only http:// and
https:// URLs would be treated this way. I would expect that file:// URLs
would have the extension.

Is this a dead issue?

John

manuelbarzi

Re: Importing URLs. Use content type or content disposition, please

hi, John,

reading and image in java is not tied to the condition to have an extension
in a file. you may have it, with or without the correct file extension, or
you may not. i currently read jpg images with .img extension, to give you an
idea. also in mac platforms you may or you may not have an extension in
files (mac initial practice was no extensions in files, now this is
changing).

so, having a URL addressed to an image file and opening the stream to it
should work. check that your image server is providing the correct mime type
when accessing this content by means of http.

regards.

On Wed, Feb 25, 2009 at 9:53 PM, John Carlson <[hidden email]> wrote:

> We are trying to download JPEG images into ImageJ through URLs that look
> like this:
>
>
> http://image.llnl.gov/cmsdk/content/urn:llnl.gov:nif:archive:9991debe-47e9-4
> 894-9e1a-7e2febf26522<http://image.llnl.gov/cmsdk/content/urn:llnl.gov:nif:archive:9991debe-47e9-4%0A894-9e1a-7e2febf26522>
>
> This won't load in ImageJ, we think because there isn't a file extension on
> the end of the URL. We aren't sure that we can modify WebDAV to add an
> extension to the end of the URL, like ?fileType=.jpg
>
> We currently have a servlet which uses a file extension at the end of the
> URL to pass to ImageJ. We use this to convert HDFs to PNG to download the
> PNG into imagej. We might continue this practice, because I am not aware
> that ImageJ can load an HDF 5 (H5) file.
>
> Can ImageJ look at HTTP Content-Type and Content-Disposition headers to
> determine the file type and file name/title? I guess only http:// and
> https:// URLs would be treated this way. I would expect that file:// URLs
> would have the extension.
>
> Is this a dead issue?
>
> John
>

Michael Schmid

Re: Java Compile Errors

In reply to this post by David Webster

Hi David,

it seems to be a problem of 'convert to plugin'.

Rename should be
run("Rename...", "title=[test]");
or, if you have a variable,
run("Rename...", "title=["+newName+"]");

For the Image Calculator, simply delete the 'IJ.imageCalculator'
line; the one with 'IJ.run' is enough.

Michael
________________________________________________________________

On 25 Feb 2009, at 20:49, David William Webster wrote:

> I was just checking out the capability of converting a
> Plugins/Macro/Record macro to a plugin, but get errors when I use
> File/Compile and Run. I am Java ignorant so I don't know what gives.
>
> My recorded macro is:
>
> run("Duplicate...", "title=tim-1.bmp");
> rename("test");
> run("Mean...", "radius=2");
> imageCalculator("Add create", "tim.bmp","test");
> //run("Image Calculator...", "image1=tim.bmp operation=Add image2=test
> create");
> selectWindow("test");
>
> The Java code is:
> import ij.*;
> import ij.process.*;
> import ij.gui.*;
> import java.awt.*;
> import ij.plugin.*;
>
> public class test2plugin_ implements PlugIn {
>
> public void run(String arg) {
> IJ.run("Duplicate...", "title=tim-1.bmp");
> IJ.rename("test");
> IJ.run("Mean...", "radius=2");
> IJ.imageCalculator("Add create", "tim.bmp","test");
> IJ.run("Image Calculator...", "image1=tim.bmp
> operation=Add image2=test create");
> IJ.selectWindow("test");
> }
>
> }
>
> and the errors are:
>
> C:\Program Files\ImageJ\plugins\test2plugin_.java:11: cannot find
> symbol
> symbol : method rename(java.lang.String)
> location: class ij.IJ
> IJ.rename("test");
> ^
> C:\Program Files\ImageJ\plugins\test2plugin_.java:13: cannot find
> symbol
> symbol : method imageCalculator
> (java.lang.String,java.lang.String,java.lang.String)
> location: class ij.IJ
> IJ.imageCalculator("Add create", "tim.bmp","test");
> ^
> 2 errors
>
> I just now took an automatic update for Java (1.6.0_10 [32 bit]),
> could
> this be the problem? Sory for being so clueless.
>
> David Webster

Volker Baecker

Re: Java Compile Errors

In reply to this post by David Webster

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello David,
the problem is that there are no methods rename and imageCalculator in
the class IJ. Remove
"IJ.imageCalculator("Add create", "tim.bmp","test");"
The next line in your code does this correctly.
Replace "IJ.rename("test");" with "IJ.run("Rename...", "test");".
Best regards,
Volker Baecker

David William Webster a écrit :

> I was just checking out the capability of converting a
> Plugins/Macro/Record macro to a plugin, but get errors when I use
> File/Compile and Run. I am Java ignorant so I don't know what gives.
>
> My recorded macro is:
>
> run("Duplicate...", "title=tim-1.bmp");
> rename("test");
> run("Mean...", "radius=2");
> imageCalculator("Add create", "tim.bmp","test");
> //run("Image Calculator...", "image1=tim.bmp operation=Add image2=test
> create");
> selectWindow("test");
>
> The Java code is:
> import ij.*;
> import ij.process.*;
> import ij.gui.*;
> import java.awt.*;
> import ij.plugin.*;
>
> public class test2plugin_ implements PlugIn {
>
> public void run(String arg) {
> IJ.run("Duplicate...", "title=tim-1.bmp");
> IJ.rename("test");
> IJ.run("Mean...", "radius=2");
> IJ.imageCalculator("Add create", "tim.bmp","test");
> IJ.run("Image Calculator...", "image1=tim.bmp
> operation=Add image2=test create");
> IJ.selectWindow("test");
> }
>
> }
>
> and the errors are:
>
> C:\Program Files\ImageJ\plugins\test2plugin_.java:11: cannot find symbol
> symbol : method rename(java.lang.String)
> location: class ij.IJ
> IJ.rename("test");
> ^
> C:\Program Files\ImageJ\plugins\test2plugin_.java:13: cannot find symbol
> symbol : method imageCalculator
> (java.lang.String,java.lang.String,java.lang.String)
> location: class ij.IJ
> IJ.imageCalculator("Add create", "tim.bmp","test");
> ^
> 2 errors
>
> I just now took an automatic update for Java (1.6.0_10 [32 bit]), could
> this be the problem? Sory for being so clueless.
>
> David Webster
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJpluixZKX7A/4oMERAmB6AJ43HUVJwFobi1dEvcVZDqBwbjt7EwCgu8+n
OZAZGM64ysJANcjm92OhYaU=
=ZD4m
-----END PGP SIGNATURE-----

--
passerelle antivirus du campus CNRS de Montpellier
--

dscho

Re: Importing URLs. Use content type or content disposition, please

In reply to this post by Zummy

Hi,

On Wed, 25 Feb 2009, John Carlson wrote:

> We are trying to download JPEG images into ImageJ through URLs that look
> like this:
>
> http://image.llnl.gov/cmsdk/content/urn:llnl.gov:nif:archive:9991debe-47e9-4
> 894-9e1a-7e2febf26522
>
> This won't load in ImageJ, we think because there isn't a file extension on
> the end of the URL.

I tried to load the image, but it came back with

ATTENTION

The IMAGE Consortium resource is now being maintained by the
Hudson Alpha Institute for Biotechnology

Please update your bookmark to:

http://image.hudsonalpha.org

You will be automatically redirected to this web site in 30 seconds
Clones continue to be available through the five IMAGE distributors.

For questions, please send email to [hidden email]

UCRL-WEB-235107
LLNL Disclaimer

I am pretty sure that ImageJ will not be redirected, as it is not a 302
redirection (HTTP level), but a HTTP-EQUIV="Refresh" redirection which
would require ImageJ to _interpret_ the loaded file as HTML (which is
completely out of ImageJ's purpose).

Maybe it works if you update the URL as suggested?

Ciao,
Dscho

David Webster

Re: Java Compile Errors

In reply to this post by Volker Baecker

That works!!

On Thu, Feb 26, 2009 at 1:06 AM, Volker Bäcker
<[hidden email]>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello David,
> the problem is that there are no methods rename and imageCalculator in
> the class IJ. Remove
> "IJ.imageCalculator("Add create", "tim.bmp","test");"
> The next line in your code does this correctly.
> Replace "IJ.rename("test");" with "IJ.run("Rename...", "test");".
> Best regards,
> Volker Baecker
>
>
> David William Webster a écrit :
> > I was just checking out the capability of converting a
> > Plugins/Macro/Record macro to a plugin, but get errors when I use
> > File/Compile and Run. I am Java ignorant so I don't know what gives.
> >
> > My recorded macro is:
> >
> > run("Duplicate...", "title=tim-1.bmp");
> > rename("test");
> > run("Mean...", "radius=2");
> > imageCalculator("Add create", "tim.bmp","test");
> > //run("Image Calculator...", "image1=tim.bmp operation=Add image2=test
> > create");
> > selectWindow("test");
> >
> > The Java code is:
> > import ij.*;
> > import ij.process.*;
> > import ij.gui.*;
> > import java.awt.*;
> > import ij.plugin.*;
> >
> > public class test2plugin_ implements PlugIn {
> >
> > public void run(String arg) {
> > IJ.run("Duplicate...", "title=tim-1.bmp");
> > IJ.rename("test");
> > IJ.run("Mean...", "radius=2");
> > IJ.imageCalculator("Add create", "tim.bmp","test");
> > IJ.run("Image Calculator...", "image1=tim.bmp
> > operation=Add image2=test create");
> > IJ.selectWindow("test");
> > }
> >
> > }
> >
> > and the errors are:
> >
> > C:\Program Files\ImageJ\plugins\test2plugin_.java:11: cannot find symbol
> > symbol : method rename(java.lang.String)
> > location: class ij.IJ
> > IJ.rename("test");
> > ^
> > C:\Program Files\ImageJ\plugins\test2plugin_.java:13: cannot find symbol
> > symbol : method imageCalculator
> > (java.lang.String,java.lang.String,java.lang.String)
> > location: class ij.IJ
> > IJ.imageCalculator("Add create", "tim.bmp","test");
> > ^
> > 2 errors
> >
> > I just now took an automatic update for Java (1.6.0_10 [32 bit]), could
> > this be the problem? Sory for being so clueless.
> >
> > David Webster
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFJpluixZKX7A/4oMERAmB6AJ43HUVJwFobi1dEvcVZDqBwbjt7EwCgu8+n
> OZAZGM64ysJANcjm92OhYaU=
> =ZD4m
> -----END PGP SIGNATURE-----
>
> --
> passerelle antivirus du campus CNRS de Montpellier
> --
>

Zummy

Re: Importing URLs. Use content type or content disposition, please

In reply to this post by manuelbarzi

Sorry, the URL is behind a firewall--it was a fake example anyway.

What we did was allow an optional /foo.jpg at the end of the HTTP URL on our
webDAV server to allow ImageJ to load the JPEG files. I have been
researching this issue some more, and it looks like IE is loading the JPEG
irrespective of what the HTTP URL extension is (perhaps it is looking at the
content and not the content-type?), and Firefox generally has to ask for
which application to launch when the HTTP URL extension isn't .jpg, .png, or
.gif. Or it loads the image as encoded if the extension is .html. ImageJ
bails when the HTTP URL extension isn't .jpg, .png or .gif (perhaps
others)--If the HTTP URL extension is .png, .jpg or .gif (perhaps others)
then it will load the JPEG image. It would be nice if ImageJ behaved more
like IE in respecting Content-Type or file contents, but perhaps that just
isn't going to happen.

When we use a servlet (and no servlet-mapping to .jpg or .jpeg. Should we
use one of these?) or perl to serve up the image and specifying parameters
on the HTTP URL usually we put &fileType=.png at the end of the HTTP URL
(even though we set the Content-Type and Content-Disposition in the
application--not necessarily in the web server) to have ImageJ intake the
file. This has been my experience.

I realize that Java has a nice way of reading in images. Unfortunately, in
ImageJ, you must have a .png or .jpg or .gif at the end of the HTTP URL to
get it to work. And ImageJ will load JPEGs with all of those HTTP URL
extensions (thanks Java).

I don't know why you can load a Jpeg into ImageJ through a HTTP URL w/ a
.img extension. I can't here. Are you using an ImageJ plugin?

There are some fall through cases in ImageJ. Perhaps testing the URL for
http:// and the Content-Type would be appropriate
John
-----Original Message-----
From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of
manuelbarzi
Sent: Thursday, February 26, 2009 12:45 AM
To: [hidden email]
Subject: Re: Importing URLs. Use content type or content disposition, please

hi, John,

reading and image in java is not tied to the condition to have an extension
in a file. you may have it, with or without the correct file extension, or
you may not. i currently read jpg images with .img extension, to give you an
idea. also in mac platforms you may or you may not have an extension in
files (mac initial practice was no extensions in files, now this is
changing).

so, having a URL addressed to an image file and opening the stream to it
should work. check that your image server is providing the correct mime type
when accessing this content by means of http.

regards.

On Wed, Feb 25, 2009 at 9:53 PM, John Carlson <[hidden email]> wrote:

> We are trying to download JPEG images into ImageJ through URLs that look
> like this:
>
>
> http://
image.llnl.gov/cmsdk/content/urn:llnl.gov:nif:archive:9991debe-47e9-4
> 894-9e1a-7e2febf26522<http://
image.llnl.gov/cmsdk/content/urn:llnl.gov:nif:archive:9991debe-47e9-4%0A894-
9e1a-7e2febf26522>
>
> This won't load in ImageJ, we think because there isn't a file extension
on

> the end of the URL. We aren't sure that we can modify WebDAV to add an
> extension to the end of the URL, like ?fileType=.jpg
>
> We currently have a servlet which uses a file extension at the end of the
> URL to pass to ImageJ. We use this to convert HDFs to PNG to download the
> PNG into imagej. We might continue this practice, because I am not aware
> that ImageJ can load an HDF 5 (H5) file.
>
> Can ImageJ look at HTTP Content-Type and Content-Disposition headers to
> determine the file type and file name/title? I guess only http:// and
> https:// URLs would be treated this way. I would expect that file://

URLs
> would have the extension.
>
> Is this a dead issue?
>
> John
>

ctrueden

Re: Importing URLs. Use content type or content disposition, please

Hi John,

> ImageJ bails when the HTTP URL extension isn't .jpg, .png or .gif (perhaps
> others)--If the HTTP URL extension is .png, .jpg or .gif (perhaps others)
> then it will load the JPEG image.

The source for ij.io.Opener.openURL(String) corroborates your observations:
http://rsb.info.nih.gov/ij/docs/source/ij/io/Opener.java.html#270

It would be nice if ImageJ behaved more like IE in respecting Content-Type
> or file contents, but perhaps that just isn't going to happen.
>

Java has convenient methods for determining content type, so it should be
doable.

Around line 286, add something like:

URLConnection conn = u.openConnection();
String contentType = conn.getContentType();
String contentDisposition = conn.getHeaderField("Content-Disposition");
//String contentEncoding = conn.getContentEncoding();
//int contentLength = conn.getContentLength();
conn.close();
...
if ((contentType.equals("image/jpeg") ||
contentType.equals("image/gif") ||
lurl.endsWith(".jpg") || lurl.endsWith(".gif") ||
lurl.endsWith(".JPG") || lurl.endsWith(".GIF"))
{
imp = openJpegOrGifUsingURL(name, u);
}
else if (contentType.equals("image/png") ||
lurl.endsWith(".png") || lurl.endsWith(".PNG"))
{
imp = openPngUsingURL(name, u);
}

Another option would be a URL content type opener plugin, that gets called
by Opener via HandleExtraFileTypes if none of the extensions match. The
advantage of this approach is that the ij.io.Opener code would not need to
change.

Anyone else have any thoughts on the merits of this?

-Curtis

On Thu, Feb 26, 2009 at 5:04 PM, John Carlson <[hidden email]> wrote:

> Sorry, the URL is behind a firewall--it was a fake example anyway.
>
> What we did was allow an optional /foo.jpg at the end of the HTTP URL on
> our
> webDAV server to allow ImageJ to load the JPEG files. I have been
> researching this issue some more, and it looks like IE is loading the JPEG
> irrespective of what the HTTP URL extension is (perhaps it is looking at
> the
> content and not the content-type?), and Firefox generally has to ask for
> which application to launch when the HTTP URL extension isn't .jpg, .png,
> or
> .gif. Or it loads the image as encoded if the extension is .html. ImageJ
> bails when the HTTP URL extension isn't .jpg, .png or .gif (perhaps
> others)--If the HTTP URL extension is .png, .jpg or .gif (perhaps others)
> then it will load the JPEG image. It would be nice if ImageJ behaved more
> like IE in respecting Content-Type or file contents, but perhaps that just
> isn't going to happen.
>
> When we use a servlet (and no servlet-mapping to .jpg or .jpeg. Should we
> use one of these?) or perl to serve up the image and specifying parameters
> on the HTTP URL usually we put &fileType=.png at the end of the HTTP URL
> (even though we set the Content-Type and Content-Disposition in the
> application--not necessarily in the web server) to have ImageJ intake the
> file. This has been my experience.
>
> I realize that Java has a nice way of reading in images. Unfortunately, in
> ImageJ, you must have a .png or .jpg or .gif at the end of the HTTP URL to
> get it to work. And ImageJ will load JPEGs with all of those HTTP URL
> extensions (thanks Java).
>
> I don't know why you can load a Jpeg into ImageJ through a HTTP URL w/ a
> .img extension. I can't here. Are you using an ImageJ plugin?
>
> There are some fall through cases in ImageJ. Perhaps testing the URL for
> http:// and the Content-Type would be appropriate
> John
> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of
> manuelbarzi
> Sent: Thursday, February 26, 2009 12:45 AM
> To: [hidden email]
> Subject: Re: Importing URLs. Use content type or content disposition,
> please
>
> hi, John,
>
> reading and image in java is not tied to the condition to have an extension
> in a file. you may have it, with or without the correct file extension, or
> you may not. i currently read jpg images with .img extension, to give you
> an
> idea. also in mac platforms you may or you may not have an extension in
> files (mac initial practice was no extensions in files, now this is
> changing).
>
> so, having a URL addressed to an image file and opening the stream to it
> should work. check that your image server is providing the correct mime
> type
> when accessing this content by means of http.
>
> regards.
>
> On Wed, Feb 25, 2009 at 9:53 PM, John Carlson <[hidden email]> wrote:
>
> > We are trying to download JPEG images into ImageJ through URLs that look
> > like this:
> >
> >
> > http://
> image.llnl.gov/cmsdk/content/urn:llnl.gov:nif:archive:9991debe-47e9-4
> > 894-9e1a-7e2febf26522<http://
>
> image.llnl.gov/cmsdk/content/urn:llnl.gov:nif:archive:9991debe-47e9-4%0A894-
> 9e1a-7e2febf26522<http://image.llnl.gov/cmsdk/content/urn:llnl.gov:nif:archive:9991debe-47e9-4%0A894-%0A9e1a-7e2febf26522>
> >
> >
> > This won't load in ImageJ, we think because there isn't a file extension
> on
> > the end of the URL. We aren't sure that we can modify WebDAV to add an
> > extension to the end of the URL, like ?fileType=.jpg
> >
> > We currently have a servlet which uses a file extension at the end of the
> > URL to pass to ImageJ. We use this to convert HDFs to PNG to download
> the
> > PNG into imagej. We might continue this practice, because I am not aware
> > that ImageJ can load an HDF 5 (H5) file.
> >
> > Can ImageJ look at HTTP Content-Type and Content-Disposition headers to
> > determine the file type and file name/title? I guess only http:// and
> > https:// URLs would be treated this way. I would expect that file://
> URLs
> > would have the extension.
> >
> > Is this a dead issue?
> >
> > John
> >
>

Wayne Rasband

Re: Importing URLs. Use content type or content disposition, please

The ImageJ 1.42k daily build opens JPEG, GIF and PNG images from URLs
based on either the extension or the content type.

-wayne

On Feb 27, 2009, at 12:33 PM, Curtis Rueden wrote:

> Hi John,
>
>
>> ImageJ bails when the HTTP URL extension isn't .jpg, .png or .gif
>> (perhaps
>> others)--If the HTTP URL extension is .png, .jpg or .gif (perhaps
>> others)
>> then it will load the JPEG image.
>
>
> The source for ij.io.Opener.openURL(String) corroborates your
> observations:
> http://rsb.info.nih.gov/ij/docs/source/ij/io/Opener.java.html#270
>
> It would be nice if ImageJ behaved more like IE in respecting
> Content-Type
>> or file contents, but perhaps that just isn't going to happen.
>>
>
> Java has convenient methods for determining content type, so it should
> be
> doable.
>
> Around line 286, add something like:
>
> URLConnection conn = u.openConnection();
> String contentType = conn.getContentType();
> String contentDisposition = conn.getHeaderField("Content-Disposition");
> //String contentEncoding = conn.getContentEncoding();
> //int contentLength = conn.getContentLength();
> conn.close();
> ...
> if ((contentType.equals("image/jpeg") ||
> contentType.equals("image/gif") ||
> lurl.endsWith(".jpg") || lurl.endsWith(".gif") ||
> lurl.endsWith(".JPG") || lurl.endsWith(".GIF"))
> {
> imp = openJpegOrGifUsingURL(name, u);
> }
> else if (contentType.equals("image/png") ||
> lurl.endsWith(".png") || lurl.endsWith(".PNG"))
> {
> imp = openPngUsingURL(name, u);
> }
>
> Another option would be a URL content type opener plugin, that gets
> called
> by Opener via HandleExtraFileTypes if none of the extensions match. The
> advantage of this approach is that the ij.io.Opener code would not
> need to
> change.
>
> Anyone else have any thoughts on the merits of this?
>
> -Curtis
>
> On Thu, Feb 26, 2009 at 5:04 PM, John Carlson <[hidden email]>
> wrote:
>
>> Sorry, the URL is behind a firewall--it was a fake example anyway.
>>
>> What we did was allow an optional /foo.jpg at the end of the HTTP URL
>> on
>> our
>> webDAV server to allow ImageJ to load the JPEG files. I have been
>> researching this issue some more, and it looks like IE is loading the
>> JPEG
>> irrespective of what the HTTP URL extension is (perhaps it is looking
>> at
>> the
>> content and not the content-type?), and Firefox generally has to ask
>> for
>> which application to launch when the HTTP URL extension isn't .jpg,
>> .png,
>> or
>> .gif. Or it loads the image as encoded if the extension is .html.
>> ImageJ
>> bails when the HTTP URL extension isn't .jpg, .png or .gif (perhaps
>> others)--If the HTTP URL extension is .png, .jpg or .gif (perhaps
>> others)
>> then it will load the JPEG image. It would be nice if ImageJ behaved
>> more
>> like IE in respecting Content-Type or file contents, but perhaps that
>> just
>> isn't going to happen.
>>
>> When we use a servlet (and no servlet-mapping to .jpg or .jpeg.
>> Should we
>> use one of these?) or perl to serve up the image and specifying
>> parameters
>> on the HTTP URL usually we put &fileType=.png at the end of the HTTP
>> URL
>> (even though we set the Content-Type and Content-Disposition in the
>> application--not necessarily in the web server) to have ImageJ intake
>> the
>> file. This has been my experience.
>>
>> I realize that Java has a nice way of reading in images.
>> Unfortunately, in
>> ImageJ, you must have a .png or .jpg or .gif at the end of the HTTP
>> URL to
>> get it to work. And ImageJ will load JPEGs with all of those HTTP URL
>> extensions (thanks Java).
>>
>> I don't know why you can load a Jpeg into ImageJ through a HTTP URL
>> w/ a
>> .img extension. I can't here. Are you using an ImageJ plugin?
>>
>> There are some fall through cases in ImageJ. Perhaps testing the URL
>> for
>> http:// and the Content-Type would be appropriate
>> John
>> -----Original Message-----
>> From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of
>> manuelbarzi
>> Sent: Thursday, February 26, 2009 12:45 AM
>> To: [hidden email]
>> Subject: Re: Importing URLs. Use content type or content disposition,
>> please
>>
>> hi, John,
>>
>> reading and image in java is not tied to the condition to have an
>> extension
>> in a file. you may have it, with or without the correct file
>> extension, or
>> you may not. i currently read jpg images with .img extension, to give
>> you
>> an
>> idea. also in mac platforms you may or you may not have an extension
>> in
>> files (mac initial practice was no extensions in files, now this is
>> changing).
>>
>> so, having a URL addressed to an image file and opening the stream to
>> it
>> should work. check that your image server is providing the correct
>> mime
>> type
>> when accessing this content by means of http.
>>
>> regards.
>>
>> On Wed, Feb 25, 2009 at 9:53 PM, John Carlson <[hidden email]>
>> wrote:
>>
>>> We are trying to download JPEG images into ImageJ through URLs that
>>> look
>>> like this:
>>>
>>>
>>> http://
>> image.llnl.gov/cmsdk/content/urn:llnl.gov:nif:archive:9991debe-47e9-4
>>> 894-9e1a-7e2febf26522<http://
>>
>> image.llnl.gov/cmsdk/content/urn:llnl.gov:nif:archive:9991debe-47e9
>> -4%0A894-
>> 9e1a-7e2febf26522<http://image.llnl.gov/cmsdk/content/urn:llnl.gov:
>> nif:archive:9991debe-47e9-4%0A894-%0A9e1a-7e2febf26522>
>>>
>>>
>>> This won't load in ImageJ, we think because there isn't a file
>>> extension
>> on
>>> the end of the URL. We aren't sure that we can modify WebDAV to
>>> add an
>>> extension to the end of the URL, like ?fileType=.jpg
>>>
>>> We currently have a servlet which uses a file extension at the end
>>> of the
>>> URL to pass to ImageJ. We use this to convert HDFs to PNG to
>>> download
>> the
>>> PNG into imagej. We might continue this practice, because I am not
>>> aware
>>> that ImageJ can load an HDF 5 (H5) file.
>>>
>>> Can ImageJ look at HTTP Content-Type and Content-Disposition headers
>>> to
>>> determine the file type and file name/title? I guess only http://
>>> and
>>> https:// URLs would be treated this way. I would expect that
>>> file://
>> URLs
>>> would have the extension.
>>>
>>> Is this a dead issue?
>>>
>>> John
>>>
>>
>