| Re: interact with iimage from the command line? [message #60439] |
Wed, 21 May 2008 20:29  |
KRDean
Messages: 69
Registered: July 2006
|
Member |
|
|
On May 21, 9:54 am, David Fanning <n...@dfanning.com> wrote:
> kBob writes:
>> I deal with imagery that can total upto 50Gb and image objects allow
>> me to navigate around these large files on a desktop Windows XP with
>> only a 1 Gb RAM. The secret is not to read the whole image, but to
>> pick at it. Pull out the chunks you need.
>
> OK, now this has got my attention.
>
> I don't suppose you have a nice little example of this,
> do you? For the life of me, I can't see how to create
> the image object so that the data is not also loaded.
> Can you please enlighten us further?
>
> Cheers,
>
> David
>
> --
> David Fanning, Ph.D.
> Fanning Software Consulting, Inc.
> Coyote's Guide to IDL Programming:http://www.dfanning.com/
> Sepore ma de ni thui. ("Perhaps thou speakest truth.")
I found out how to do this from Mark Piper at ITTVIS in his Advance
IDL course. The code is very similiar to what Galloy presents at his
site. You can find the ITTVIS version on their ftp site ...
ftp://ftp.ittvis.com/training/IDL_advanced/
You'll find the code in the zip file under the tiler directory.
Just like Galloy's, it is a GUI example using JPEG2000 as input. It
was a great way to learn how to use IDL Objects.
IDL's help has a nice discussion too, "Adding Tiling to Your
Application".
Not knowing the source of Adam's data, I use GeoTIFF. You can use
ENVI's input routines, but IDL's READ_TIFF can read a rectangle
region, so you are not limited to just JPEG2000.
So to be more enlighting, take the JPEG2000 out and input the IDL's
READ_TIFF with its SUB_RECT keyword.
However, first use the IDLgrImage to set up the "tiles". Instead of
the JPEG2000 tiles, the tiles are the dimensions of the input files,
for example, the 100x10000 arrays. No need to read in the data. Let
the OBJECT GRAPHICS determine what you need to pull.
Use the VIEWPLANE_RECT in IDLgrView to input your full sample data
location.
Let the QueryRequiredTiles in IDLgrWindow determine what file you
need to open and the rectangle area you need to pull with READ_TIFF,
SUB_RECT.
Hopefully, this will help Adam...
Kelly Dean
Fort Collins, CO
|
|
|
|
| Re: interact with iimage from the command line? [message #60445 is a reply to message #60439] |
Wed, 21 May 2008 11:29  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
pgrigis@gmail.com writes:
> Here's a quick working code. The trick of course
> is to transform the intensity array into a true color
> image:
Oh, I see. I guess I've been stuck on assuming the
person was starting off with a 24-bit image to begin with.
If the person has a 2D array of 16-bit data, I can see
how this could potentially be useful. One might construct,
for example, a 16-bit color table for CT data that colored
different tissues, based on their data range, differently.
Interesting idea. Thanks.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: interact with iimage from the command line? [message #60446 is a reply to message #60445] |
Wed, 21 May 2008 11:13 |
pgrigis
Messages: 436
Registered: September 2007
|
Senior Member |
|
|
David Fanning wrote:
> pgrigis@gmail.com writes:
>
>> Well, it is true that 8 bit color tables are the only ones
>> that are easily accessible from IDL, but there is nothing
>> to stop users to display false color images with color
>> tables with more than 256 elements, apart having to write
>> a few lines of code. As a matter of fact, sometimes I wonder
>> whether we should have some nice color table with, say,
>> 1024 elements...
>
> Well, what few lines of code would you write? I'd like
> to see how something like this would work.
Here's a quick working code. The trick of course
is to transform the intensity array into a true color
image:
;create 512 element color table
;by combining 2 different color tables
rl=bytarr(512)
gl=bytarr(512)
bl=bytarr(512)
loadct,3
tvlct,r,g,b,/get
rl[0:255]=r
gl[0:255]=g
bl[0:255]=b
loadct,5
tvlct,r,g,b,/get
rl[256:511]=r
gl[256:511]=g
bl[256:511]=b
;create some data
im=dist(512,512)
;scale data
im=(im-min(im))/(max(im)-min(im))*511
;create true color image
im2=bytarr(512,512,3)
im2[*,*,0]=rl[im]
im2[*,*,1]=gl[im]
im2[*,*,2]=bl[im]
;display image
tv,im2,true=3
Ciao,
Paolo
>
> Cheers,
>
> David
> --
> David Fanning, Ph.D.
> Fanning Software Consulting, Inc.
> Coyote's Guide to IDL Programming: http://www.dfanning.com/
> Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: interact with iimage from the command line? [message #60447 is a reply to message #60446] |
Wed, 21 May 2008 10:54 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
pgrigis@gmail.com writes:
> Well, it is true that 8 bit color tables are the only ones
> that are easily accessible from IDL, but there is nothing
> to stop users to display false color images with color
> tables with more than 256 elements, apart having to write
> a few lines of code. As a matter of fact, sometimes I wonder
> whether we should have some nice color table with, say,
> 1024 elements...
Well, what few lines of code would you write? I'd like
to see how something like this would work.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
|
|
| Re: interact with iimage from the command line? [message #60451 is a reply to message #60449] |
Wed, 21 May 2008 10:38 |
pgrigis
Messages: 436
Registered: September 2007
|
Senior Member |
|
|
[skip]
>> On the note of color range, is there really no 'true color'
>> colortable? Not that my eye can really distinguish better than about
>> 30 colors on a screen, but I would have expected there to be 16 and 24
>> bit color tables, not just 8 bit.
>
> No, just 8 bit color tables. 16 and 24 bit image arrays
> have their colors built in. There is no need for color
> lookup tables. (There is nothing to "look up", the color
> is there staring you in the face.)
Well, it is true that 8 bit color tables are the only ones
that are easily accessible from IDL, but there is nothing
to stop users to display false color images with color
tables with more than 256 elements, apart having to write
a few lines of code. As a matter of fact, sometimes I wonder
whether we should have some nice color table with, say,
1024 elements...
Ciao,
Paolo
>
> Cheers,
>
> David
> --
> David Fanning, Ph.D.
> Fanning Software Consulting, Inc.
> Coyote's Guide to IDL Programming: http://www.dfanning.com/
> Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
|
|
|
|
|
|
| Re: interact with iimage from the command line? [message #60455 is a reply to message #60454] |
Wed, 21 May 2008 09:58 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Keflavich writes:
> Right - what I was hoping for is a display that downsamples the
> dimension that is too large WITHOUT downsampling the data itself.
I don't understand what this means. I still think you are getting
the data and the *display* of the data mixed up.
> I don't think TV does that very easily.
TV doesn't do anything but light up pixels on a display according
to information you supply it. It's a lot dumber than you give it
credit for, but maybe that's a good thing.
> Maybe kBob's method will do that.
Hard to say. If I didn't know Kelly better I would have
sworn he was hitting the sauce early today. But, I'm curious,
too.
> On the note of color range, is there really no 'true color'
> colortable? Not that my eye can really distinguish better than about
> 30 colors on a screen, but I would have expected there to be 16 and 24
> bit color tables, not just 8 bit.
No, just 8 bit color tables. 16 and 24 bit image arrays
have their colors built in. There is no need for color
lookup tables. (There is nothing to "look up", the color
is there staring you in the face.)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: interact with iimage from the command line? [message #60456 is a reply to message #60454] |
Wed, 21 May 2008 09:46 |
Keflavich
Messages: 19
Registered: May 2008
|
Junior Member |
|
|
On May 21, 10:04 am, David Fanning <n...@dfanning.com> wrote:
> Keflavichwrites:
>> If, for example, I use iimage,congrid(data,
>> 400,400), it gives me pretty much what I want: a data display that can
>> be interacted with. However, congrid (or indexing) changes the actual
>> state of the data, which is not ideal.
>
> Well, look. I doubt you have a display that can accommodate
> an image that has a 10000 in one of its dimensions, so you
> are going to change the "state" of the data no matter what
> you do. And don't make the mistake of confusing your data
> with the *display* of the data. They are two completely
> different things. For one thing, it is doubtful whether
> your data is in the range of 0 to 255, the only kind of
> "data" that can be displayed on the computer.
Right - what I was hoping for is a display that downsamples the
dimension that is too large WITHOUT downsampling the data itself. I
don't think TV does that very easily. Maybe kBob's method will do
that.
On the note of color range, is there really no 'true color'
colortable? Not that my eye can really distinguish better than about
30 colors on a screen, but I would have expected there to be 16 and 24
bit color tables, not just 8 bit.
Adam
|
|
|
|
| Re: interact with iimage from the command line? [message #60457 is a reply to message #60456] |
Wed, 21 May 2008 09:04 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Keflavich writes:
> If, for example, I use iimage,congrid(data,
> 400,400), it gives me pretty much what I want: a data display that can
> be interacted with. However, congrid (or indexing) changes the actual
> state of the data, which is not ideal.
Well, look. I doubt you have a display that can accommodate
an image that has a 10000 in one of its dimensions, so you
are going to change the "state" of the data no matter what
you do. And don't make the mistake of confusing your data
with the *display* of the data. They are two completely
different things. For one thing, it is doubtful whether
your data is in the range of 0 to 255, the only kind of
"data" that can be displayed on the computer.
> Those are both neat codes, and I think I will be able to use them for
> this task. There isn't a single display code that does both, though,
> is there?
Depends on how much money you have in your programming budget
for contractors. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: interact with iimage from the command line? [message #60458 is a reply to message #60457] |
Wed, 21 May 2008 08:55 |
Keflavich
Messages: 19
Registered: May 2008
|
Junior Member |
|
|
On May 21, 6:22 am, David Fanning <n...@dfanning.com> wrote:
> Keflavichwrites:
>> tvimage? Is that equivalent to tv, tvscl?
>
> TVIMAGE is equivalent to TV in the way a Porche
> is equivalent to a Buick. :-)
Alright, I'll have to explore that.
>> Anyway, what I really want to do is display fully sampled data with an
>> aspect ratio that allows it all to be viewed at once, but also display
>> it in an interactive window so that a user can zoom in on parts of the
>> data and possibly even change the transfer function interactively. I
>> think the 'tv' is wrong for this sort of task - am I mistaken?
>
> Yes, you are mistaken. TV allows you to display images. Period.
> All the other stuff you are interested in has to do with how the
> user interacts with data. That, generally speaking, involves
> widget programming. Since you are just starting in IDL, let
> me give you some advice. You could learn widget programming
> fifty times over before you make any progress on programming
> an iTool.
You're right that I don't want to program any widgets. I was hoping a
widget existed that already did what I wanted - it looks like iimage
nearly does that. If, for example, I use iimage,congrid(data,
400,400), it gives me pretty much what I want: a data display that can
be interacted with. However, congrid (or indexing) changes the actual
state of the data, which is not ideal.
>> atv
>> comes somewhat close, but I don't think it can display weird aspect
>> ratios either.
>
> Aspect ratios are determined simply by how you resize the image.
> In the simplest case, just make an IDL graphics window in the
> aspect ratio you want, and use TVIMAGE to display the data.
> There you go, done.
>
> Have a look at a program like ZIMAGE or XSTRETCH. (You can
> find them both on my web page.) These do the kinds of things
> you are looking for, if not exactly the way you want to do
> them. I guarantee you, they will be a LOT easier to understand
> than any iTool you pick up.
Those are both neat codes, and I think I will be able to use them for
this task. There isn't a single display code that does both, though,
is there?
>> Honestly, though, I haven't figured out a good way to display even
>> downsampled data on the tv. I'm fairly inexperienced with IDL, but I
>> have a lot of experience with other data languages. Is there any way
>> to take, e.g., every 10th element along a given axis?
>
> This, my friend, is what IDL lives to do!
>
> IDL> s = Size(image, /Dimensions) & Print, s
> 100 10000
> IDL> each10 = Indgen(1000) * 10
> IDL> resampledImage = image[*,each10]
>
> But, this is *much* more easily accomplished by simply resizing
> your array:
>
> IDL> resampledImage = Rebin(image, 100, 1000)
>
> Or, if you want it some "weird" size:
>
> IDL> weirdImage = Congrid(image, 500, 700)
>
> Any of those images can be displayed with a TV command. :-)
Ah... ok. I had tried 'rebin' but didn't have an integer factor size
in my 2nd dimension. The [*,each10] trick I think I should have
known, but have never used. Thanks.
Adam
|
|
|
|
|
|
| Re: interact with iimage from the command line? [message #60461 is a reply to message #60459] |
Wed, 21 May 2008 08:29 |
KRDean
Messages: 69
Registered: July 2006
|
Member |
|
|
On May 20, 11:43 pm, Keflavich <keflav...@gmail.com> wrote:
> tvimage? Is that equivalent to tv, tvscl?
>
> Anyway, what I really want to do is display fully sampled data with an
> aspect ratio that allows it all to be viewed at once, but also display
> it in an interactive window so that a user can zoom in on parts of the
> data and possibly even change the transfer function interactively. I
> think the 'tv' is wrong for this sort of task - am I mistaken? atv
> comes somewhat close, but I don't think it can display weird aspect
> ratios either.
>
> Honestly, though, I haven't figured out a good way to display even
> downsampled data on the tv. I'm fairly inexperienced with IDL, but I
> have a lot of experience with other data languages. Is there any way
> to take, e.g., every 10th element along a given axis?
>
> Thanks,
> Adam
Try Image Objects ( IDLgrImage, IDLgrView, IDLgeModels, IDLgrWindow ).
I deal with imagery that can total upto 50Gb and image objects allow
me to navigate around these large files on a desktop Windows XP with
only a 1 Gb RAM. The secret is not to read the whole image, but to
pick at it. Pull out the chunks you need.
IDLgrImage is used to setup the image area. Use IDLgrView to set the
VIEWPLAN_RECT, then use the Window object method QueryRequiredTiles
for the tile areas, either from IDLgrBuffer, IDGgrWindow, or
WIDGET_DRAW. This information allows me to pull out the desired sector
and display or save the fully sample data from the large image.
For a smaller display of the whole image, I use CONGRID or REBIN, such
as David points out.
Using Object Graphics, I can create a command line (IDLgrBuffer) or
Widget (WIDGET_DRAW or IDLgrWindow) to pull out the sector by giving a
X/Y location or clicking on a point in the Widget display.
Not to say it cannot be done in direct graphics. Following the same
idea as before, pull out the chunks you want. Use POINT_LUN to
navigate to the spot on the image. This works great with single images
that are 2 to 4 Gb. However, the image object's QueryRequiredTiles
saved time for me in developing a similiar routine in direct graphics
to handle multiple image sets.
Good Luck,
Kelly Dean
Fort Collins, CO
|
|
|
|
| Re: interact with iimage from the command line? [message #60465 is a reply to message #60461] |
Wed, 21 May 2008 05:22 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Keflavich writes:
> tvimage? Is that equivalent to tv, tvscl?
TVIMAGE is equivalent to TV in the way a Porche
is equivalent to a Buick. :-)
> Anyway, what I really want to do is display fully sampled data with an
> aspect ratio that allows it all to be viewed at once, but also display
> it in an interactive window so that a user can zoom in on parts of the
> data and possibly even change the transfer function interactively. I
> think the 'tv' is wrong for this sort of task - am I mistaken?
Yes, you are mistaken. TV allows you to display images. Period.
All the other stuff you are interested in has to do with how the
user interacts with data. That, generally speaking, involves
widget programming. Since you are just starting in IDL, let
me give you some advice. You could learn widget programming
fifty times over before you make any progress on programming
an iTool.
> atv
> comes somewhat close, but I don't think it can display weird aspect
> ratios either.
Aspect ratios are determined simply by how you resize the image.
In the simplest case, just make an IDL graphics window in the
aspect ratio you want, and use TVIMAGE to display the data.
There you go, done.
Have a look at a program like ZIMAGE or XSTRETCH. (You can
find them both on my web page.) These do the kinds of things
you are looking for, if not exactly the way you want to do
them. I guarantee you, they will be a LOT easier to understand
than any iTool you pick up.
> Honestly, though, I haven't figured out a good way to display even
> downsampled data on the tv. I'm fairly inexperienced with IDL, but I
> have a lot of experience with other data languages. Is there any way
> to take, e.g., every 10th element along a given axis?
This, my friend, is what IDL lives to do!
IDL> s = Size(image, /Dimensions) & Print, s
100 10000
IDL> each10 = Indgen(1000) * 10
IDL> resampledImage = image[*,each10]
But, this is *much* more easily accomplished by simply resizing
your array:
IDL> resampledImage = Rebin(image, 100, 1000)
Or, if you want it some "weird" size:
IDL> weirdImage = Congrid(image, 500, 700)
Any of those images can be displayed with a TV command. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
|
|
| Re: interact with iimage from the command line? [message #60469 is a reply to message #60468] |
Tue, 20 May 2008 22:43 |
Keflavich
Messages: 19
Registered: May 2008
|
Junior Member |
|
|
tvimage? Is that equivalent to tv, tvscl?
Anyway, what I really want to do is display fully sampled data with an
aspect ratio that allows it all to be viewed at once, but also display
it in an interactive window so that a user can zoom in on parts of the
data and possibly even change the transfer function interactively. I
think the 'tv' is wrong for this sort of task - am I mistaken? atv
comes somewhat close, but I don't think it can display weird aspect
ratios either.
Honestly, though, I haven't figured out a good way to display even
downsampled data on the tv. I'm fairly inexperienced with IDL, but I
have a lot of experience with other data languages. Is there any way
to take, e.g., every 10th element along a given axis?
Thanks,
Adam
|
|
|
|
|
|
| Re: interact with iimage from the command line? [message #60561 is a reply to message #60439] |
Thu, 22 May 2008 11:21 |
MP
Messages: 15
Registered: March 2006
|
Junior Member |
|
|
On May 21, 9:29 pm, kBob <KRD...@gmail.com> wrote:
> I found out how to do this from Mark Piper at ITTVIS in his Advance
> IDL course. The code is very similiar to what Galloy presents at his
> site.
Thank you Kelly, but I can't take credit -- Mike actually wrote that
example while we were officemates here at VIS. I've only modified it.
The version Mike has on his website is an improved form of this
original.
mp
|
|
|
|
| Re: interact with iimage from the command line? [message #60568 is a reply to message #60439] |
Thu, 22 May 2008 07:59 |
Keflavich
Messages: 19
Registered: May 2008
|
Junior Member |
|
|
On May 21, 9:29 pm, kBob <KRD...@gmail.com> wrote:
> On May 21, 9:54 am, David Fanning <n...@dfanning.com> wrote:
>
>
>
>> kBob writes:
>>> I deal with imagery that can total upto 50Gb and image objects allow
>>> me to navigate around these large files on a desktop Windows XP with
>>> only a 1 Gb RAM. The secret is not to read the whole image, but to
>>> pick at it. Pull out the chunks you need.
>
>> OK, now this has got my attention.
>
>> I don't suppose you have a nice little example of this,
>> do you? For the life of me, I can't see how to create
>> the image object so that the data is not also loaded.
>> Can you please enlighten us further?
>
>> Cheers,
>
>> David
>
>> --
>> David Fanning, Ph.D.
>> Fanning Software Consulting, Inc.
>> Coyote's Guide to IDL Programming:http://www.dfanning.com/
>> Sepore ma de ni thui. ("Perhaps thou speakest truth.")
>
> I found out how to do this from Mark Piper at ITTVIS in his Advance
> IDL course. The code is very similiar to what Galloy presents at his
> site. You can find the ITTVIS version on their ftp site ...
>
> ftp://ftp.ittvis.com/training/IDL_advanced/
>
> You'll find the code in the zip file under the tiler directory.
>
> Just like Galloy's, it is a GUI example using JPEG2000 as input. It
> was a great way to learn how to use IDL Objects.
>
> IDL's help has a nice discussion too, "Adding Tiling to Your
> Application".
>
> Not knowing the source of Adam's data, I use GeoTIFF. You can use
> ENVI's input routines, but IDL's READ_TIFF can read a rectangle
> region, so you are not limited to just JPEG2000.
>
> So to be more enlighting, take the JPEG2000 out and input the IDL's
> READ_TIFF with its SUB_RECT keyword.
>
> However, first use the IDLgrImage to set up the "tiles". Instead of
> the JPEG2000 tiles, the tiles are the dimensions of the input files,
> for example, the 100x10000 arrays. No need to read in the data. Let
> the OBJECT GRAPHICS determine what you need to pull.
>
> Use the VIEWPLANE_RECT in IDLgrView to input your full sample data
> location.
>
> Let the QueryRequiredTiles in IDLgrWindow determine what file you
> need to open and the rectangle area you need to pull with READ_TIFF,
> SUB_RECT.
>
> Hopefully, this will help Adam...
>
> Kelly Dean
> Fort Collins, CO
Thanks for the detailed information. It will take me a while to
process all that. I haven't done any work with compressed image
formats (jpg,tiff) yet; my data is simply numerical arrays. But I
think the method you've described might be the right method to
visualize my whole data set.
Adam
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
