Ed - Thanks for the explanation - while it may not be as flexible as what we had originally planned, it makes a lot more sense as to why it was implemented this way - especially in light of some people's belief that users operate out of multiple folders at once...I guess both philosophies have merit. Thanks for the response. Next time you're in town, let me know (assuming it won't violate the new "edict"). Would enjoy seeing you.

Bob: Good to hear from you, I hope all is well. Since I wasn?t involved with your initial conversations with Al I can?t comment on that. As you well know operational aspects of software can change quite a bit as a project progresses due to many other issues. Having said that? I hope I didn?t create the impression that this save/keep operation ?bags? the operator and is not well implemented. Yes, if you don?t know how it works then you can get bagged as with anything else (DVE & timeline paths, Timelines and macros, etc. the list goes on and on) but knowing how it works creates a lot of power. The save functions I mentioned above didn?t address e-mem operations only file saves. Ever since I started on this SS project (over a year ago) the basic operational definitions were pretty much already determined by Al. The current (v15.0) concept behind saving to specific folders is this: When the operator performs a Grab this only places the image in a cache buffer. A Keep will then create two files: a .BMP (for the thumbnail of course) and the .gva (meta) file which are saved in the current working directory. So now that part of cache is allocated to this image. [Sorry if I?m getting a little basic but I want other readers to understand this]. When the actual image information is saved it is saved in the same folder - which is the folder selected at the time of the Keep. The whole concept behind this is that a TD can have multiple folders and the Kalypso will keep track of where to save the images. After grabbing and keeping multiple images the operator can go to Image Manager and select the desired images and save them. Let?s say there are 20 images that the operator wants to save in 4 different folders. If planned correctly, Kalypso will manage all this and save things where they were ?kept?. A couple of scenarios might be local news or sports. The TD has four folders, one for each news show of the day. In sports the TD could have multiple folders say, ESPN Generic, ESPN Slates, ESPN Hoops. When the TD performs the grab/keep they should do it in the folder where they want that image to eventually be saved then Kalypso will take care of the rest. This is great when doing multiple saves. You can just select all images then save them, no need to change folders for saving in different locations. This was done to expedite the saving process. This is all tied to the concept that we grab now and save later. With the current (v15.0) system when you save later (maybe because you have a lot of animations) you don?t have to manage a thing it?s already been set. If you Keep an image in an undesired folder you can then copy them using Image Server.

Craig: In all of our lab testing we haven't seen this - that certainly doesn't mean it can't happen. After talking to some of the software engineers at Grass we all agree that the system can?t actually convert an image from one line rate to another. What is possible is that the meta data became corrupt or was old meta data from a previous 525 image and that somehow became associated with your new image. We?d love to know any more details you have concerning this. With all the added functionality of the new Still Store there are just so many different things that could be happening here. There are new caveats associated with operation of the system and then there are simply some new bugs. Bottom line, this shouldn?t be possible and we need to find out how it occurred. Any other info you (or anyone else on this forum) have would be a great help. Thanks, Ed

[quote="Ed Collins"]Let?s say you grab/keep several images and you also changed the working directory a few times in between grabs/keeps then you go back to Image Manager and tell the system to save the images in cache. The system will save those images to whatever working directory is displayed during the grab. This can be very powerful if you know what it is doing. Since the old system could only save to the current working directory the current mindset is that images will be saved to the currently displayed directory and that may not necessarily be true.[/quote] Ed, not to put you on the spot, but this begs the question: I checked my paperwork, and I can verify that when Al & I started working on the updated Still Store software a few years ago, one of the 1st options presented was to have the Still Store operate exactly as you describe above. Al & I almost immediately threw out this idea because of 2 reasons: (1) it would bag operators, as you pointed to in your answer; and (2) it goes completly against every other file save paradigm on the Kalypso, where no matter what working folder you're in, you can always save what you have to another folder...you're not locked in to whatever E-Mem folder you were in when you learned a register, for example. Al & I had gone through all of this years ago & the decision had been made to allow the same flexibily in the Still Store File Saves that the user has always in the rest of the Kalypso. My question is why was the decision made to backtrack to a paradigm that had already been determined to be less intuitive to the user and less consistent with the rest of the switcher? Again, I'm not trying to put you on the spot, but the decision to go this route seems "curious", especially in light of the options that were available years ago.

Ed, Thanks for your reply. First of all, any stills that I copied into my personal folder via image server were 1080 stills from folders containing other 1080 stills only. Secondly, I did in fact save (not just keep) all of these stills to only one location - my personal folder. That said: the next day when I set the directory path to my personal folder, I was in fact able to see the thumbnails of all of these stills. So the issue was not that I didn't save them, or that I saved them to different locations; all of the files were present in my folder the next day (8 stills in total). The issue was that (while I used these 8 stills successfully during my previous show all in 1080 format) when I went to load some of them the next day, I received a line rate mismatch on 3 of the 8 because they had somehow been converted to 525. So in short - these were 1080 stills, running at 1080 all day, re-saved at the end of the night - a portion of which were converted to 525... Software aside, I can't think of anything operational that a TD could do to change the format of a still running at 1080 to 525. Any thoughts? Best, Craig

Craig: It?s possible that you saved your stills in a different location where you thought you were saving. I?ll get to the 525 images in a second. Since the SS Environment (the window with all of the images) has now been opened up to look at multiple locations there needed to be some rules implemented to make this work. Newly grabbed images will be saved in the current working directory that was displayed when the grab occurred. So if you grabbed an image while the default folder was displayed (in the bottom white data/path box) and then performed a save the image will be saved in the default folder. Even if you changed the working directory to your personal folder the image will be saved in the default folder because that?s where you were when you grabbed it. Again, there had to be some rules applied here. The system has to guess where you actually want to do a save so it saves wherever you are when you grab the image. This can work for and against you, but if you know what its doing they you?re okay. If you used an old folder that also had some 525 images in it and you inadvertently saved your newly grabbed images to another location (by changing your working directory before a save) then you would not see these images in your personal folder. Another gotcha? that has some TDs mumbling under their breath is the Keep vs. Save functions. The Keep only places the currently grabbed image in cache while the Save actually saves the image to working directory that was selected during the grab. This can get confusing if you perform several grabs then keep the images but don?t save them. The keep is very powerful because you can grab animations then set loops etc. all before saving ? which takes forever. Let?s say you grab/keep several images and you also changed the working directory a few times in between grabs/keeps then you go back to Image Manager and tell the system to save the images in cache. The system will save those images to whatever working directory is displayed during the grab. This can be very powerful if you know what it is doing. Since the old system could only save to the current working directory the current mindset is that images will be saved to the currently displayed directory and that may not necessarily be true. So I recommend that when you?re performing new grabs be sure you?re in the folder where you eventually want those images saved. If you?re not then all is not lost. You can always go to the Image Server and physically copy files from one location to another. Hope this helps, Ed