Changing values of one image from ENVI

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

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

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
>
>

ENVI_GET_DATA is really built for accessing a single band of an image
cube. Neither it nor ENVI_GET_SLICE seems appropriate to me for what
you're trying to do, if i'm reading your problem correctly. The best
way to look at the difference between the two routines is to think
about an image cube's interleave. If your cube is in BSQ interleave,
ENVI_GET_DATA should be fast b/c it returns full bands, and for BSQ
interleave, bands are contiguous on disk. If your cube is in a BIP or
BIL interleave, ENVI_GET_SLICE is probably the better choice b/c,
again, that's the way the data are arranged on disk, and accessing the
data in contiguous chunks is faster. ENVI_GET_SLICE is also of course
the way to go if you want entire spectra for any number of pixels,
including subsets that are complete slices through the cube (ie, you
only want 10 pixels out of a line rather than the entire line).

However, all that said, both of those routines are for *loading* data
into memory only. If you want to be able to read in a few pixel
values, change them, and write those pixels back out without changing
the rest of the file, I'd forget both of those routines and have a
look at the IDL routine ASSOC().

Jeff

> 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.

There's no canned routine in ENVI to do this, but you could ceate your
own using IDL's OPENW, POINT_LUN, WRITEU, and FREE_LUN. Just be sure
to make a backup of your data until you get it working right!

Chris

Oops, that should be OPENU, not OPENW.

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.

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.

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

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

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.