imagej MER basics - Page 14

Previous 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 Next
Author Message
hortonheardawho


Posts: 3465

Reply: 261



PostPosted: September 8, 2012 8:19 AM 

The test HS30EXR images are here.

I just had to share this one:

I am more than a little impressed by this "out of the box" image of the Moon and Jupiter.

dx


Posts: 1661

Reply: 262



PostPosted: September 8, 2012 9:24 AM 

h>>>

Splendid shot in 261 and this without a tripod! Your shot of the bird without it is also quite remarkable. The image stability is what...fuzzy logic? Some 15 years ago it was going to be used for everything that required a steady movement...trains to water pumps to cameras, etc.

Did you pick up any lens' to switch between different shot conditions?

Guess I'll have to get my little sweetheart out this fall for some extraterrestrial shots. You may just have inspired me enough to do it. But right now its pouring...no sunsets, birds or stars here...LOLOL

yt
dx


hortonheardawho


Posts: 3465

Reply: 263



PostPosted: September 8, 2012 9:41 AM 

dx, the Moon&Jupiter shots were done on a tripod - but the bird was hand held.

For a giggle you might look at the EXIF data from the camera for the pictures.

Just click on the camera name link immediately to the left of the picture.

Here is the link to the exif data for the cropped bird image.

I will be trying out the "3D" feature today.

I think I'm going to be disappointed - as it is really a "fudge". IE. two images are taken manually and hopefully nothing moves between the two shots.

I am thinking about buying a "real" 3D camera like the FinePix W3 for the October trip. Of course I will then have to buy a 3D TV...

I have been thinking about producing a Mars "real" 3D DVD ( not the cheesy color glasses versions ) from the many, many color 3Ds I have made over the years.

Do you think anyone would buy it? Maybe if I gave it away?

dx


Posts: 1661

Reply: 264



PostPosted: September 9, 2012 9:26 AM 

h>>>

I'm looking at Oppy Raw Microscopic Images from Sol 3064...15 images. Very interesting features I would like to resolve. Hard to tell shadow from hole from rock!!!

Have you worked with these as colored 3D's? Is imageJ useful here to merge? Is there a formula you have worked out for these kinds of MI's?

I have tried earlier MI's without success.

Thanks for any help.

yt
dx

dx


Posts: 1661

Reply: 265



PostPosted: September 9, 2012 9:42 AM 

h>>>

A few things I've noticed in your 263. I checked out the EXIF and saw that the 'lighting' data was 'unknown'. That seems strange to me since the shot can be either indoors or outdoors-perhaps telephoto shots are unknown lighting conditions.

While viewing the 2 videos of the FinePix W3 I note that the 2 people in the presentations had glasses on and one must also have a 3D TV to view the images or movie.

This looks like a fine camera to purchase-have you bought the 3D TV?

However, I am not into 3D-but I certainly like the idea of not wearing glasses to see the images.

yt
dx


Barsoomer


Posts: 344

Reply: 266



PostPosted: October 4, 2012 8:20 PM 

Not sure if this is an appropriate question here, but I'm wondering if we could synthesize 3D stereo images from the MI image stacks.

The background here is that they take several MI images at different distances, and that is useful to reconstruct an "extended depth of field" image. However, I thinking one might also extract elevation information from the stack.

The idea would be for each pixel there would a stack frame in which it has the "best" focus and that frame would identify the elevation dimension. Of course that raises the issue of how one would identify the best focus frame for a pixel. As an first guess, it might be the frame in which its brightness level has the greatest difference from its neighboring pixels. That might identify it at least for some of the pixels. Ok, it gets more complicated for the "ambiguous" pixels.

If one had the elevation information, I think Horton already has a plugin that could use that to render 3D perspectives as he did for the FAMARS af microscope images.

hortonheardawho


Posts: 3465

Reply: 267



PostPosted: October 4, 2012 8:43 PM 

The imagej Extended Depth of Field plugin produces a height map along with the EDF image - which another plugin uses to create a "3D" stereo pair ( or anaglyph if you wish ). I used this capability a bit during the Phoenix mission on the MI images.

The problem in this mission is the EDF image is produced in-camera - but the funny B&W frames returned are probably the height maps that may work with the imagej 3D software. I'll give it a try later on tonight.

hortonheardawho


Posts: 3465

Reply: 268



PostPosted: October 4, 2012 11:29 PM 

sol 0054 3D EDF using imagej:

It works with a bit of fiddling - but as with the Phoenix images the 3D fine detail is not to be believed.

I am truly DISAPPOINTED that "real" 3D offsets were not done to "prove" the in-camera EDF 3D.

Here is another example ( with no alteration of the color ):

Yuk. Again, not very good. The problem may be with the imagej Anaglyph plugin- but I don't think the NASA EDF 3D ( if ever released ) will be any better.

Come-oon guys, do some real MAHLI 3D.

For those of you who may want to fiddle with MAHLI 3D when the EDF images are done here is the imagej recipe:

0) install the imagej plugin Anaglyph.

1) rename the MAHLI EDF image to "Output" and the er, topology image to "Topology" ( "Height Map" if using version 1.6 of the plugin. The topology image seems to immediately follow the EDF image. )

2) use the command Analyze on the Topology image to determine the height range.

3) start the Anaglyph plugin. Be very patient. Go away and have a coffee. Maybe another. Maybe a whole pot ( of coffee that is ) - or maybe two ( pots ) when you come back there will be a window that requests the range ( max height ) and the 3D format you want. Press OK - and go have another pot ( or two ) of coffee.

Did I mention this plug-in is incredibly slow? Did I mention it was free??

Barsoomer


Posts: 344

Reply: 269



PostPosted: October 5, 2012 12:47 AM 

The first image in reply 268 looks good out of the box.

It takes my brain a while to adjust to the second image because of the plunging surfaces, but once it does the 3D actually looks very good!

I was actually wondering if this could be applied to Oppy images where they don't bother with a stereo pair for the MI or the second eye is interminably delayed in coming down.

hortonheardawho


Posts: 3465

Reply: 270



PostPosted: October 5, 2012 7:30 AM 

Here is some sol 0058 MAHLI 3D.

First, a comment about the Anaglyph plugin. The reason I believe that it seemed to take so long to produce 3D is ( I suspect) a "memory leak" in the plug-in code.

What this means is every time the plug-in runs there is less "free" memory available - so the operating system resorts to "paging" - which means more and more "swapping" disk I/O must be done to continue running. This results in slower and slower processing times.

I sometimes forget that even with all the fancy development tools programmers still make elementary mistakes.

There is a simple way around the problem: restart imagej every time before running the plug-in.

OK, here is why I will never use this plug-in again - and why I think MAHLI is running a con with this fake 3D:

Here is a MAHLI EDF 3D:

WOW, he says at first glance. Magic!

But then he looks at a 100% detail:

Not so cool any more. The small pebbles as determined by their shadows are flat as pancakes. There are disturbing "unphysical" ripples in the image like some glitch in the matrix.

So the advanced technology is not good enough to be confused with magic.

Here's why:

This is the height map ( Topology - zero adjusted ) of the MAHLI EDF 3D above. If you look at it in detail you will NOT find any hint of the pebbles - and you will see that the contour lines are quite jagged and don't correspond to local shadow cues. ( actually you need a superposition of the image on the topology to see that - but I can't do everything at once. )

No amount of cleverness can overcome the limitations of the height map and the 3D is not magic - it's just wrong.

If you stand far enough away to view the MAHLI EDF 3D then it looks "OK". But some of us ( me ) like our 3D up close and personal. Shape detail matter when looking for biology.

But, once again, the geologists running the mission are saying shape isn't important - so why invest any resources in recording it?

But we want to wow you with,er, "science" - so we will wave our magic wand and produce "3D" for the masses.

It makes me sad that there will be no real 3D from the MAHLI camera.

One final note: There is no relationship between the Height Map file name and the EDF file name. Another "hide it in plain sight" decision by the MSL team. Yay team ( NOT ).

hortonheardawho


Posts: 3465

Reply: 271



PostPosted: October 5, 2012 8:59 AM 

sol 0058 EDFC EDF 3D X2:

Last rant on this topic:

Count yourself lucky if you can't see the 3D in the above image.

Compare and contrast this image with this real 3D ( colorized ) from Opportunity:

Aaahh. What a treat for the eyes.

Enough said.

BTW, it does appear that the Height Map image is the one immediately following the EDF image - once all the images are down-linked. Until then it's guesswork.

Barsoomer


Posts: 344

Reply: 272



PostPosted: October 5, 2012 12:20 PM 

I see. The problem is that the resolution in the z-direction is much less than the resolutions in the x and y directions.

So this is not good for closeups. Or one could use a negative exaggeration factor in the z-direction so that the resolutions match better, but then one might just as well present the flat image.

hortonheardawho


Posts: 3465

Reply: 273



PostPosted: October 5, 2012 1:53 PM 

The MAHLI EDF problem is not only limited to the derived 3D.

If you look closely at the first 3D in reply 271 - ignoring the 3D - you can see what looks like several mats of dendrites. But are they features - or bugs of the image stacking software? They look weird in 3D - and 2D. So is a "real" feature or not?

By filtering the "real" images through a complex calculation and presenting ONLY the magical results, there is always an "explanation" for any weird fine detail feature: Oh, our magicians - I mean technicians - say it's only a "processing artifact".

Of course, without the original data there is no way for anyone including the technicians - I mean magicians - to verify that assertion.

One of the totally weird features of computational mathematics is that proofs of correctness for even simple programs are far more complex than the programs that are being proved as "correct". Think about that for a moment.

All of this grief could be relieved by a simple offsetting 3D at the "sharpest" focus zoom.

But it will not happen. Instead we will get golly-gee-whiz HD movies of the rover zooming across the crater floor, snoopy's scarf flapping in the breeze while all the time the whos will be silently waving their communication appendages at the tops of their tiny dust collection orifices.

( Man, do I need a break from Mars. )

My brother is arriving this evening to take care of mom while I am away and I plan to do a long neglected backup of my 500GB data drive for the next few days - so it may be a while before I post again.

MPJ


Posts: 250

Reply: 274



PostPosted: October 5, 2012 2:35 PM 

Horton, I completely understand you...
This is the reason I am only marginally interested in the images - which are great and often suggestive of biology to be honest but nobody seems to trust images except geologists in regards to geologic features - and only wait for the analytical results of the SAM/Chemin laboratory which seems to be the only way to establish some new(old) facts.

dX


Posts: 1661

Reply: 275



PostPosted: October 6, 2012 6:22 AM 

h>>>

I tried to work out those MALI images as you have and was very disturbed as to the results and now I know why. I could not discern an answer. But your selected definitions and analysis in 270 271 and 273 have given me the answer. I obviously did not post any images for I did not have the explanations. Thank you for those...for I knew there was something difficult to understand from the 3D's I was producing or Mars was a very different place indeed, which, in my mind it isn't.

On another note, my beautiful comp totally died several days ago. It won't work and imageJ will not install on my iPad2. It will be some time before I get it back up and running if I do at all so there will be no picture posts from me in the near future. I may look into a MAC.

Enjoy your sabbatical.

yt
dx

hortonheardawho


Posts: 3465

Reply: 276



PostPosted: March 5, 2013 3:42 PM 

There hasn't been any new red meat from either Curiosity or Oppy for a few days, so I bit the bullet and modified my imagej plugin PDS Reader to read the Curiosity img files.

Here are a few test Curiosity images from the Analyst's Notebook:

sol 0000 front Hazcam after landing:

sol 0002 navcam of skycrane rocket pits:

sol 0013 chemcam of rocks:

The chemcam is the ONLY science camera with images in the notebook so far.

If the great silence continues I will reprocess all the chemcam images using original data.

AND, if anyone is interested I will post my modified imagej PDS Reader plugin here.

LWS


Posts: 3062

Reply: 277



PostPosted: March 5, 2013 7:30 PM 

Hort; I'm interested

Winston

MPJ


Posts: 250

Reply: 278



PostPosted: March 6, 2013 3:32 AM 

I'm interested too (ChemCam real raw images, imagej plugin)!

hortonheardawho


Posts: 3465

Reply: 279



PostPosted: March 6, 2013 9:18 AM 

Copy and paste everything between the cut-lines and save to a file named PDS_READER_NEW.java in the imagej plugin directory and then compile the plugin.
It will then appear in the plugin menu list as PDS Reader New

----------------------------------------

import ij.plugin.*;
import java.awt.*;
import java.io.*;
import ij.*;
import ij.io.*;
import ij.process.*;
import ij.measure.*;

/** Opens and displays PDS images. Does not work with compressed images */
public class PDS_Reader_New extends ImagePlus implements PlugIn {

private static final String TITLE = "PDS Reader";
private String directory, fileName;
private DataInputStream f;
private StringBuffer info = new StringBuffer(512);
private double bscale, bzero;
String keyword, value, line = "", sampleType, encodingType="",mapScale="";
private int recordBytes,bitsPerPixel;

public void run(String arg) {
OpenDialog od = new OpenDialog("Open PDS...", arg);
directory = od.getDirectory();
fileName = od.getFileName();
if (fileName==null)
return;
IJ.showStatus("Opening: " + directory + fileName);
FileInfo fi = null;
try {
if (!checkFileType(directory+fileName)) {
IJ.showMessage(TITLE, "This does not appear to be a PDS image file.");
//return;
}
fi = getInfo();
} catch (IOException e) {
IJ.showMessage(TITLE, ""+e);
return;
}
if (fi!=null && fi.width>0 && fi.height>0) {
FileOpener fo = new FileOpener(fi);
ImagePlus imp = fo.open(false);
ImageProcessor ip = imp.getProcessor();
setProcessor(fileName, ip);
setCalibration(imp.getCalibration());
setProperty("Info", getHeaderInfo());
if (arg.equals("")) show();
} //else
//IJ.error("This does not appear to be a PDS file.");
IJ.showStatus("");
}

FileInfo getInfo() throws IOException {
FileInfo fi = new FileInfo();
fi.fileName = fileName;
fi.directory = directory;
fi.width = 0;
fi.height = 0;
fi.offset = 0;

BufferedReader f = new BufferedReader(new FileReader(directory+fileName));
while (!line.trim().equals("END")) {//read label until we get to the END statement

line = f.readLine();
//System.out.println(line);
//IJ.write(line);
if (line == null) break;
line = line.replace('"',' ');
if (line.trim().equals("")) continue;
if (line.indexOf("=") > 0) {
keyword = line.substring(0,line.indexOf("=")).trim();
value = line.substring(line.indexOf("=")+1,line.length()).trim().toUpperCase();
}
else continue;
if (value.length() == 0) continue;
if (keyword.equals("LINES")) {
fi.height = getInteger(value);
continue;
}
if (keyword.equals("LINE_SAMPLES")) {
fi.width = getInteger(value);
continue;
}
if (keyword.equals("RECORD_BYTES")) {
recordBytes = getInteger(value);
continue;
}
if (keyword.equals("^IMAGE")) { //will only work if image pointer follows record bytes keyword
//System.out.println("imagepointer="+value);
try {fi.offset = Integer.parseInt(value);}
catch (NumberFormatException e) {
if (value.indexOf("(") >= 0) {
fi.fileName = value.trim().substring(value.indexOf("(")+2,value.lastIndexOf(","));
fi.offset = Integer.parseInt(value.substring(value.indexOf(",")+1,value.lastIndexOf(")")));
}
else {
fi.fileName = value;
fi.offset = 0;
}
}
// fi.fileName = fi.fileName.substring(0,fi.fileName.lastIndexOf(".")) +".IMG"; }
fi.offset = (fi.offset-1) * recordBytes;
//System.out.println("offset="+String.valueOf(fi.offset));
continue;
}
if (keyword.equals("SAMPLE_BITS")) {
bitsPerPixel = getInteger(value);
//System.out.println("samplebits="+value);
continue;
}
if (keyword.equals("SAMPLE_TYPE")) {
sampleType = value;
//System.out.println("sampletype="+value);
continue;
}
if (keyword.equals("SCALING_FACTOR")) {
bscale = getFloat(value);
continue;
}
if (keyword.equals("OFFSET")) {
bzero = getFloat(value);
continue;
}
if (keyword.equals("ENCODING_TYPE")) {
encodingType = value;
continue;
}
if (keyword.equals("MAP_SCALE") ||
keyword.equals("MINIMUM_LATITUDE") ||
keyword.equals("MAXIMUM_LATITUDE") ||
keyword.equals("MINIMUM_LONGITUDE") ||
keyword.equals("MAXIMUM_LONGITUDE") ||
keyword.equals("EASTERNMOST_LONGITUDE") ||
keyword.equals("WESTERNMOST_LONGITUDE") ||
keyword.equals("MAP_PROJECTION_TYPE")
) {
IJ.write(keyword +" = " + value); // display map scale value
continue;
}
} // end of label parsing

if (bitsPerPixel==8 ) fi.fileType = FileInfo.GRAY8;
else if (bitsPerPixel==16) {
fi.fileType = FileInfo.GRAY16_UNSIGNED;
if (sampleType.equals("VAX_INTEGER")
|| sampleType.equals("PC_INTEGER"))
fi.intelByteOrder = true;
}
else if ((bitsPerPixel==32) && sampleType.equals("UNSIGNED_INTEGER"))
fi.fileType = FileInfo.GRAY32_INT;
else if ((bitsPerPixel==32) && sampleType.equals("PC_REAL")){
fi.fileType = FileInfo.GRAY32_FLOAT;
fi.intelByteOrder = true;
}
else if ((bitsPerPixel==-32) && sampleType.equals("REAL"))
fi.fileType = FileInfo.GRAY32_FLOAT;
else {
IJ.showMessage(TITLE, "bitsPerPixel="+bitsPerPixel+"sampleType="+sampleType+" SAMPLE_BITS must be 8, 16, 32 or -32 (float).");
f.close();
return null;
}
line = f.readLine();
if (encodingType.length() > 0 && !encodingType.equals("NONE")) {
IJ.showMessage(TITLE, "Cannot open PDS compressed images.");
f.close();
return null;
}
f.close();
if (fi.fileType==FileInfo.GRAY16_SIGNED && !(bscale==1.0&&bzero==32768.0)) {
double[] coeff = new double[2];
coeff[0] = -32768.0;
coeff[1] = 1.0;
fi.calibrationFunction = Calibration.STRAIGHT_LINE;
fi.coefficients = coeff;
fi.valueUnit = "gray value";
}
return fi;
}

String getString(int length) throws IOException {
byte[] b = new byte[length];
f.read(b);
return new String(b);
}

int getInteger(String s) {
//s = s.substring(10, 30);
//s = s.trim();
return Integer.parseInt(s);
}

double getFloat(String s) {
//s = s.substring(10, 30);
//s = s.trim();
Double d;
try {d = new Double(s);}
catch (NumberFormatException e){d = null;}
if (d!=null)
return(d.doubleValue());
else
return 0.0;
}

String getHeaderInfo() {
return new String(info);
}
boolean checkFileType(String path) throws IOException {
InputStream is;
byte[] buf = new byte[132];
is = new FileInputStream(path);
is.read(buf, 0, 132);
is.close();
int b0=buf[0]&255, b1=buf[1]&255, b2=buf[2]&255, b3=buf[3]&255;

// PDS ("CCSD", XXCD, NJPL, XXNJ, PDSX,ODLX)
if ((b0==67 && b1==67 && b2==83 && b3==68 ) ||
(b2==67 && b3==67) ||
(b0==78 && b1==74 && b2==80 && b3==76) ||
(b2==78 && b3==74) ||
(b0==80 && b1==68 && b2==83) ||
(b0==79 && b1==68 && b2==76))
return true;
else
{
IJ.showMessage(TITLE, "File Type:"+b0+b1+b2+b3);
return false;
}
}

}


----------------------------------------

Barsoomer


Posts: 344

Reply: 280



PostPosted: March 15, 2013 2:27 PM 

link

Above is where the rems data from the PDS release, including the humidity data, is stored. The REMS data are stored as comma-separated values in ASCII files, which should make them easy to parse or view in a simple text editor. The .FMT file in the label directory specifies which columns are devoted to the humidity data. There are several columns of 64-bit integers starting at column 72 for different "channels." Note sure what the different channels signify. The values are uncalibrated so it is unclear how to translate them into, say, millibars, but it might be possible to see trends for the different Sols.

Sorry if this is the wrong thread for this.

Previous 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 Next


Join the conversation:















Very Happy Smile Sad Surprised
Shocked Confused Cool Laughing
Mad Razz Embarassed Crying or Very Sad
Evil or Very Mad Twisted Evil Rolling Eyes Wink
Powered by MTSmileys