Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
Re: interact with iimage from the command line?
Keflavich writes: > I'd like to use iimage to display some data that is extremely unwieldy > to direct display - I'm trying to show some 100x10,000 arrays. To > make this useable, I would like to resample the data or change its > aspect ratio to display more nicely. This can be done interactively > in iimage, but I couldn't find anything telling me how to get it to > happen from the command line. Can anyone tell me how to use this? > Better yet, can anyone point me to documentation on interacting with > iTools from the command line? iImage!? From the command line!? I think I'm going to go have another beer. Are you *sure* this is what your job requirements are? I'd have thought a solution would have suggested itself with TVIMAGE in about half a minute. 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.")
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
Sorry David, I had not checked your site for the TVIMAGE code before posting. However, I was unable to get it to work with any of my data... I'll have to look more closely at it. Adam
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.")
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
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.")
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
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.")
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
> 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. Nevermind. I found out that true color is certainly possible for idl image display. device,true_color=24 should do it. Adam
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.")
Keflavich writes: > Nevermind. I found out that true color is certainly possible for idl > image display. device,true_color=24 should do it. Oh, my goodness, you didn't copy someone's start-up file, did you!? About 80% of the time that will pitch you back to the 1970's. If you want to keep using that TV command, you will have to use the TRUE keyword to tell it how your 24-bit image is interleaved. (TVIMAGE will figure all of this out for you.) 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.")
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? I think he means doing something like this example: http://michaelgalloy.com/2006/04/15/idlgrimage-tiling-in-idl -62.html This example uses a JPEG2000 image as an example file, so the "pull out the chunks you need" part is easy. But it is an example of how to use tiles with IDLgrImage and IDLgrWindow. Mike -- www.michaelgalloy.com Tech-X Corporation Software Developer II
[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.")
mgalloy@gmail.com writes: > I think he means doing something like this example: > > http://michaelgalloy.com/2006/04/15/idlgrimage-tiling-in-idl -62.html > > This example uses a JPEG2000 image as an example file, so the "pull > out the chunks you need" part is easy. But it is an example of how to > use tiles with IDLgrImage and IDLgrWindow. Ah, so the image object and the data are separate entities (e.g., two different objects in your example). I can see how this can work, but it would work a lot better if ITTVIS would release image tiling routines (a la ENVI) for us to use. Save us from having to put all our data into JPEG2000 files. :-) 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.")
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.")
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.")
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.")
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
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