| Re: Changing values of one image from ENVI [message #62222] |
Sat, 30 August 2008 16:17  |
jeffnettles4870
Messages: 111
Registered: October 2006
|
Senior Member |
|
|
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
|
|
|
|
| Re: Changing values of one image from ENVI [message #62241 is a reply to message #62222] |
Fri, 29 August 2008 17:15  |
Jonathan Greenberg
Messages: 91
Registered: November 2002
|
Member |
|
|
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
|
|
|
|
| Re: Changing values of one image from ENVI [message #62317 is a reply to message #62241] |
Sun, 31 August 2008 08:30 |
devin.white
Messages: 50
Registered: March 2007
|
Member |
|
|
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.
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
