imagej MER basics - Page 3

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


Posts: 1661

Reply: 41



PostPosted: April 18, 2012 5:44 PM 

...well I tried the other R images at the JPL site and got nothing but mild coloration....but did discover the 8 bit requirement for all images if you want to stack'em...Geez, that was a throw-back...imagej would not give in to produce an image. Read the title after you download the image file and you will see the difference in bit technology.

Stones forever Man!!!Stones forever!

yt
dx


Fred


Posts: 73

Reply: 42



PostPosted: April 18, 2012 5:49 PM 


From my reading you can install the Macros in the drop down window and have them on stand-by for processing. Just run across that when I was trying to figure out the trip around the barn and through the woods. I am still not satisfied with my understanding.

I would request a side-bar on the " Bit Depth error" during the filter merging process. Can you shed some light. Is this a built in distraction from NASA?

dx


Posts: 1661

Reply: 43



PostPosted: April 18, 2012 5:51 PM 

horton>>>

I will tackle the macros in a little while...still adjusting to reading your works and applying them...Geez, I've got 5 screens open, but I thank you very much for your concern over a few of us remaining on the MRB who are willing to know just a little bit of what you know.

Many thanks. Its worth it.

yt
dx

dx


Posts: 1661

Reply: 44



PostPosted: April 19, 2012 1:11 AM 

...to clarify my 41 post>>>what I noticed is that all the images in the stack must be the same. If there are 2-8 bit images then use them and if there are no bits mentioned then use them.
Its a matter of not stacking different images.
In this case assignment for 'stacking' images there are 7-R images to look at for the synthetic color map. One of them, R3, is an 8 bit-85K image while the remaining R images are RGB, 340K. Yet all images contain a size of 320x272.

You will see the image info when you open them in imagej.

yt
dx

Fred


Posts: 73

Reply: 45



PostPosted: April 19, 2012 4:10 AM 


Thanks dx, I was getting a bit depth error. I will look a little closer at image info on imagej. I join you in thinking Hort for what he has done already and will continue I am sure.

dx


Posts: 1661

Reply: 46



PostPosted: April 19, 2012 9:40 AM 

horton>>>

you're post 40.

Do you mean that imagej knows where to place the stacked images to create a correct macro?

yt
dx

hortonheardawho


Posts: 3465

Reply: 47



PostPosted: April 19, 2012 11:02 AM 

The imagej command Image / Color / Stack to RGB assumes the order of the images is R,G,B in the stack.

Re: the raw images bit depth...

As a first step, I routinely convert the raw images one by one to 16 bit by using the command Image / Type / 16-Bit - and then multiply by 255 to stretch the range from 0-255 to 0-65025.

For unknown reasons, some of the raw images are 8 bit B&W JPG images - but most have been converted from the 12bit camera data as received on Earth to RGB JPG - where the three channels are not exactly the same in the darkest part of the image! I think this might be a bug in the routine used to convert the raw data to JPG. I haven't actually checked this for a while so it might be fixed now.

For a while, after I first noticed this ( very shortly into the mission ), I thought the "extra" RGB information was a clever encoding of the 12 bit data in the 3 x 8 bit RGB JPG - but I couldn't find a pattern that could be used to unscramble the egg.

Speaking of such things...

Most of the original data received from the rover is already compressed using ICER encoding, which allows for very high compression ratios ( like 400:1 ).

One of my constant concerns is how much of the fine detail in the images is JPG artifacts of ICER artifacts. That's why I like 3D images with all the filter data combined - and multiple images in general ( such as the MI zoom sequences )

Why do I go to all this trouble? Because, ( leaning in close and whispering ) because, I see "things in these images" ( leaning back and raising his voice ) "things that I don't think should be there if Mars is dead".

( Sure I'm crazy: I learned Relativistic Quantum Mechanics - and understand that your firm and unshakable perceptions are mostly delusions. )

Kevin


Posts: xxx

Reply: 48



PostPosted: April 20, 2012 4:28 AM 

Amazing 3D renditions of the MER better than anything NASA has:

http://www.nicksotiriadis.gr/?page_id=287

Don Davis


Posts: 12

Reply: 49



PostPosted: April 20, 2012 5:10 PM 

The raw jpeg releases are stretched in brightness enough to lose detail in highlights. They are hopelessly compromised as sources of color images, that should be based on the actual range of gray tones represented in each color channel.

It's fun to play with the JPEGs and to try to 'reconstruct' what they probably look like based on past color images. But you practically have to already know what the final result should be.
The color chart closeups at the start of the mission were probably the least mutilated by the preliminary release treatment, as they filled the frame and allowed for a gray to be established.

The sadly vanished site of Daniel Crofty was a great place to see the difference between using the ratty jpegs and the later actual data releases.

hortonheardawho


Posts: 3465

Reply: 50



PostPosted: April 20, 2012 6:16 PM 

Er, Don, the stretching is mostly in the shadows - not the highlights. I ( almost ) routinely apply a square root transform on the JPG images to recover the shadow details.

For example from these L4,L5,L6 images:


I created this image:


The "key" was converting the raw images to 16 bit images and then applying the square root transform.

I also applied a lens / filter correction to each filter image.

Yes, you do almost to have to know what the picture will look like when using just the JPG images.

I "white balance" my images by driving blue areas to gray. ( There ain't no blue skies or blue sand on Mars. ) At best there is a satisfying black looking away from the horizon.

I use the JPGs as an artist would use the colors on his palette and imagej as my brush. What I do is art - not science.

And what this topic is about is sharing the artistic knowledge I have developed over the years using that brush.

dx


Posts: 1661

Reply: 51



PostPosted: April 20, 2012 6:41 PM 

HERE HERE, horton.

yt
dx

Don Davis


Posts: 12

Reply: 52



PostPosted: April 20, 2012 7:49 PM 

Yes the jpegs are great for 'artisic' works. I have seen people trying to do 'spectral analysis' with them elsewhere.

The loss of highlights example I was thinking of was actually from the NAVCAM. Your last example looks too blue, but heck, what's wrong with a little extra B in ones art? Smile

Don Davis


Posts: 12

Reply: 53



PostPosted: April 20, 2012 8:34 PM 

I guess I'm going to have to with comparisons I used to frequent are gone.

Here is a nice example from the UMSF forum comparing color products made from the contrasty jpeg releases and the calibrated data:

http://www.unmannedspaceflight.com/index.php?act=attach&type=post&id=22424

hortonheardawho


Posts: 3465

Reply: 54



PostPosted: April 20, 2012 10:30 PM 

sol 2852 ( Feb 1, 2012 ) square root processing of a Navcam L0 sunset image:

The same 12bit to 8 bit compression scheme seems to be used for all the cameras.

Er, I don't visit the other site - ever.

By the way, Don, do you do any MER image processing using imagej? Why are you commenting about something other than imagej MER processing on this topic? I want to keep the discussion focused. Please comment about unrelated topics somewhere else. Maybe at the other place. ( Can you tell I'm a little annoyed? )

hortonheardawho


Posts: 3465

Reply: 55



PostPosted: April 20, 2012 10:44 PM 

By the way, imagej is great for processing the original data - once it is released:


Opportunity sol 11-1924 ( Feb 6, 2004 - Jun 22, 2009 ) comparison of rover deck near sundial:

Don Davis


Posts: 12

Reply: 56



PostPosted: April 21, 2012 3:42 AM 

Your methods of trying to rescue the jpegs are commendable, but I was pointing out the heritage of better material to work from than the tonally mutilated JPEGs. Your procedure done on them would be a worthy experiment.

I, like others, use Photoshop to make color images, very simply placing the L4,5,and 6 filtered images in the RGB channels.
Then I adjust curves to try to return the initial results to something that looks reasonable. The results I have seen from the real data by others are so superior I dispair of wasting time with the JPEGs, and only play with exceptional subjects like that sunset postcard.

Don Davis


Posts: 12

Reply: 57



PostPosted: April 21, 2012 3:47 AM 

looks like you did indeed go for the gold, the fresh sundial image using the real data looks good.

Fred


Posts: 73

Reply: 58



PostPosted: April 21, 2012 5:23 AM 


Good to hear from you Don. Could you define "real data." I like the sound of that.

I knew there were some heavy hitters in the shadows.....

hortonheardawho


Posts: 3465

Reply: 59



PostPosted: April 21, 2012 10:54 AM 

Please do not press this button again.

"We apologize for the inconvenience.

Don Davis


Posts: 12

Reply: 60



PostPosted: April 21, 2012 11:38 AM 

Since the software this thread is devoted to apparently works with the better image source data, I would suggest that be the first place to harvest the raw materials for such processing.

Emily Lakdawalla brought attention to this nice interface at the PDS Imaging Node:

[link]

Under the "Select Mission" window at top left, click "Mars Exploration Rover."
click 'Regular' in the "Image Type" box in the center, ."
Under "Planet Day Number," type in the sol number(s).
On the left, under "Product Search," click "Get Results."
All the images from that sol appear. Click on any one of them, and you'll get the option to download it in whatever format you like -- JPEG, PNG, TIFF, or GIF.

Why try to work around the shortcomings in the preliminary release jpegs if you have a choice? The real data seems generally less contrasty, spot checks indeed show brighter areas in some PANCAM jpegs going up against the 'white ceiling' while the later coorisponding PDS releases do not.

There is also a nice img to png converter Bjorn Johnson has written but alas it seems to not be Mac compatible.

Previous 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 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