Posted by
Zummy on
Feb 26, 2009; 11:04pm
URL: http://imagej.273.s1.nabble.com/Java-Compile-Errors-tp3693536p3693539.html
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
>