| Changing values of one image from ENVI [message #62270] |
Fri, 29 August 2008 08:20  |
txominhermos
Messages: 25
Registered: October 2005
|
Junior Member |
|
|
Hello,
I would like to change some pixel values of one image loaded with
ENVI_OPEN_FILE, but I cannot load the entire image in memory (this is
a very big image).
What I do is to access and process some specific regions of the image
using ENVI_GET_DATA, by defining subsets in DIMS.
I really wonder if there is any keyword in the procedure
ENVI_WRITE_ENVI_FILE, or other procedure (something inverse to
ENVI_GET_DATA) to perform this, because the only choice that I know is
to load the whole image in memory in IDL and write it again.
Thanks
Txomin
|
|
|
|
|
|
| Re: Changing values of one image from ENVI [message #62313 is a reply to message #62270] |
Sun, 31 August 2008 17:07  |
jeffnettles4870
Messages: 111
Registered: October 2006
|
Senior Member |
|
|
On Aug 31, 2:37 pm, Jonathan Greenberg <jgrn...@gmail.com> wrote:
> Again, the question is do you need to use a full image to do spatial
> analysis? There are *some* analyses that really require in the entire
> image, but local neighborhood spatial analyses are not one of the ones
> that need ENVI_GET_DATA -- its much more scalable to simply pull a set
> of lines using ENVI_GET_SLICE the size of your window into an array
> rather than running on the entire dataset. If you have the memory and
> small enough images, ENVI_GET_DATA can work fine, but with increasing
> image sizes (I routinely work with images that range from 1gb to
> 100gb), I come across a lot of code that does not scale because of
> that one command, when it only takes a few more lines of code to
> perform tiled analyses.
>
> Is the overhead incurred by repeated use of ENVI_GET_SLICE vs.
> ENVI_GET_DATA significant as compared to the total time of processing
> an image (assuming memory issues are not an issue)? Has anyone done
> any tests on this?
>
> --j
I think the point is that ENVI routines give you many different ways
to access your data, and the best choice of which to use depends on
what you want to do with the data. I often think of ENVI_GET_SLICE
and ENVI_GET_DATA routines as tiling routines that just return a
single tile :) If you simply want to read in a few pixels, do it -
you have that ability using either ENVI_GET_SLICE or ASSOC(). Or, as
Chris pointed out, you can POINT_LUN to whatever you need to get to.
I use these routines in different situations all the time. The real
issues here are the format of your data and what you're trying to do
with those data. If you were, for example, trying to just operate on
band 1 of an image cube, why would you bother with ENVI_GET_SLICE?
ENVI_GET_DATA seems much simpler to me in that case.
Jeff
|
|
|
|
| Re: Changing values of one image from ENVI [message #62316 is a reply to message #62270] |
Sun, 31 August 2008 11:37 |
Jonathan Greenberg
Messages: 91
Registered: November 2002
|
Member |
|
|
Again, the question is do you need to use a full image to do spatial
analysis? There are *some* analyses that really require in the entire
image, but local neighborhood spatial analyses are not one of the ones
that need ENVI_GET_DATA -- its much more scalable to simply pull a set
of lines using ENVI_GET_SLICE the size of your window into an array
rather than running on the entire dataset. If you have the memory and
small enough images, ENVI_GET_DATA can work fine, but with increasing
image sizes (I routinely work with images that range from 1gb to
100gb), I come across a lot of code that does not scale because of
that one command, when it only takes a few more lines of code to
perform tiled analyses.
Is the overhead incurred by repeated use of ENVI_GET_SLICE vs.
ENVI_GET_DATA significant as compared to the total time of processing
an image (assuming memory issues are not an issue)? Has anyone done
any tests on this?
--j
On Aug 31, 8:30 am, "devin.wh...@gmail.com" <devin.wh...@gmail.com>
wrote:
> On Aug 29, 8:15 pm, Jonathan Greenberg <jgrn...@gmail.com> wrote:
>
>
>
>> Txomin:
>
>> I need to write a thread at some point extolling how much I hate
>> "ENVI_GET_DATA" -- its one of the most useless commands in the ENVI
>> language. I am a HUGE fan of ENVI_GET_SLICE and, if you want to get
>> more complicated, use the built-in envi tiling routines (which are
>> really just envi_get_slice x a number of lines dependent on memory).
>> The idea is, you read one line at a time, process it, write the output
>> one line at a time... No memory issues, fast read/write, all good.
>
>> --j
>
>> On Aug 29, 8:20 am, txominher...@gmail.com wrote:
>
>>> Hello,
>>> I would like to change some pixel values of one image loaded with
>>> ENVI_OPEN_FILE, but I cannot load the entire image in memory (this is
>>> a very big image).
>>> What I do is to access and process some specific regions of the image
>>> using ENVI_GET_DATA, by defining subsets in DIMS.
>>> I really wonder if there is any keyword in the procedure
>>> ENVI_WRITE_ENVI_FILE, or other procedure (something inverse to
>>> ENVI_GET_DATA) to perform this, because the only choice that I know is
>>> to load the whole image in memory in IDL and write it again.
>
>>> Thanks
>
>>> Txomin- Hide quoted text -
>
>> - Show quoted text -
>
> ENVI_GET_DATA, ENVI_GET_SLICE, and the ENVI tiling mechanism represent
> three different ways to access image data. I sometimes will use all
> three in the same program--depending on what kind of processing I need
> to do. They each have their strengths and weaknesses. For example,
> if I was interested in multi-scale spatial processing (not spectral),
> ENVI_GET_SLICE would be pretty useless since I can only retrieve one
> line at a time at full spatal resolution and the data is ordered in
> BIL or BIP. ENVI_GET_DATA is perfect for that task. The tiling
> mechanism is very flexible and can go either way, but requires more
> programming overhead and is often overkill for the task at hand.
> However, there are times when it is the best option. I wouldn't
> recommend it for this task, though.
|
|
|
|
|
|
|
|
| Re: Changing values of one image from ENVI [message #62564 is a reply to message #62311] |
Mon, 15 September 2008 02:23 |
txominhermos
Messages: 25
Registered: October 2005
|
Junior Member |
|
|
On 1 sep, 06:56, Chris Jengo <cje...@gmail.com> wrote:
> I don't think the original poster's question is about READING data,
> though, it's about EDITING data. That is, modifying an existing file
> without having to read in the entire dataset (using whatever method),
> modify the desired values, then write to a new file. Lots of wasted I/
> O for some small edits (but preserves integrity of original data...).
>
> Chris
Hi, sorry for the delay, i have been on vacances until today
Chris is rigth, the original question is about EDITING data.
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
