Re: MCN-L Digitization procedures
Amalyah Keshet wrote: Mike: What application are you using to generate derivatives "on the fly"? Can you tell us more about this? Amalyah Keshet One approach is to script ImageMagick (http://www.imagemagick.org/), a free image conversion/resizing/manipulation tool. Actually at least one of the big enterprise DAMS just uses ImageMagick as a module. - Original Message - From: Mike Rippy To: mcn-l@mcn.edu Sent: Friday, January 06, 2006 4:25 PM Subject: Re: MCN-L Digitization procedures Oh, by the way.Our plan here for our collection photography is to store theraw file, create a master tif file (that has been corrected for dust, color, etc.)and from that make various jpg derivitives (as needed). However, do to storage space limitations, we are considering using a new system thatuses an application togenerate derivatives on "the fly" to be delivered to our users. Saving the cost of storing each derivative file. We also keep each file seperated in a folder for that file type, raw, tif, jpg_screen, jpg_thumb. Be sure to pay close attention to you naming conventions also, http://www.tasi.ac.uk/advice/creating/filenaming.html. This is also covered in the National Archives guidelines. Mike. m...@concretecomputing.com 12/27/2005 9:54 PM There's probably no perfect way to store images on a filesystem, so maybe it should just come down to personal preference. Unless you need specific security settings--for example, so some people can see/edit some files but not others. In that case, you might want to build the arrangement to mirror the security arrangement, which will make setup easier, and corrections a lot easier. There might also be other factors like that, that I'm not thinking of. Anyone else? The "right" way to store images is in some kind of databasing system that keeps image metadata alongside the image files so that you can always find them again by working your way down a hierarchical tree (bad but demonstrative example: Paintings--19th Century--Impressionism--American--Cassatt, Mary--The Cup of Tea) or by searching according to subject, artist, media, title, etc. It's hard to impossible to duplicate that with directories on disk and maintain it reliably. These syst ems go all the way from $0 to high six figures in cash, and take significant effort and time to implement and maintain. good luck, Matt Perian Sully wrote: Hi all: I'm currently developing our digitization procedures and I was wondering what other institutions do to organize their content. I'm planning on photographing identification database images in a fairly high resolution jpg and photograph in RAW for publication-quality. Once the images are downloaded, I'll be processing them in small, medium and large dpi (72/150/?) and saving the original. What I'm really sort of curious about is how many different file sizes people save in and if they keep file directories for each size or lump them all together. Hope you're all having some relaxing holidays! Perian Sully Collection Database and Records Administrator Judah L. Magnes Museum 2911 Russell Street Berkeley, CA 94705 (510) 549-6950 ext. 335 --- You are currently subscribed to mcn_mcn-l as: m...@concretecomputing.com To unsubscribe send a blank email to leave-mcn_mcn-l-12800...@listserver.americaneagle.com --- You are currently subscribed to mcn_mcn-l as: akes...@imj.org.il To unsubscribe send a blank email to leave-mcn_mcn-l-12800...@listserver.americaneagle.com --- You are currently subscribed to mcn_mcn-l as: m...@concretecomputing.com To unsubscribe send a blank email to leave-mcn_mcn-l-12800...@listserver.americaneagle.com --- You are currently subscribed to mcn_mcn-l as: rlancefi...@mail.wesleyan.edu To unsubscribe send a blank email to leave-mcn_mcn-l-12800...@listserver.americaneagle.com
Re: MCN-L Digitization procedures
Mike: What application are you using to generate derivatives "on the fly"? Can you tell us more about this? Amalyah Keshet - Original Message - From: Mike Rippy To: mcn-l@mcn.edu Sent: Friday, January 06, 2006 4:25 PM Subject: Re: MCN-L Digitization procedures Oh, by the way.Our plan here for our collection photography is to store theraw file, create a master tif file (that has been corrected for dust, color, etc.)and from that make various jpg derivitives (as needed). However, do to storage space limitations, we are considering using a new system thatuses an application togenerate derivatives on "the fly" to be delivered to our users. Saving the cost of storing each derivative file. We also keep each file seperated in a folder for that file type, raw, tif, jpg_screen, jpg_thumb. Be sure to pay close attention to you naming conventions also, http://www.tasi.ac.uk/advice/creating/filenaming.html. This is also covered in the National Archives guidelines. Mike. m...@concretecomputing.com 12/27/2005 9:54 PM There's probably no perfect way to store images on a filesystem, so maybe it should just come down to personal preference. Unless you need specific security settings--for example, so some people can see/edit some files but not others. In that case, you might want to build the arrangement to mirror the security arrangement, which will make setup easier, and corrections a lot easier. There might also be other factors like that, that I'm not thinking of. Anyone else?The "right" way to store images is in some kind of databasing system that keeps image metadata alongside the image files so that you can always find them again by working your way down a hierarchical tree (bad but demonstrative example: Paintings--19th Century--Impressionism--American--Cassatt, Mary--The Cup of Tea) or by searching according to subject, artist, media, title, etc. It's hard to impossible to duplicate that with directories on disk and maintain it reliably. These syst ems go all the way from $0 to high six figures in cash, and take significant effort and time to implement and maintain.good luck,MattPerian Sully wrote: Hi all: I'm currently developing our digitization procedures and I was wondering what other institutions do to organize their content. I'm planning on photographing identification database images in a fairly high resolution jpg and photograph in RAW for publication-quality. Once the images are downloaded, I'll be processing them in small, medium and large dpi (72/150/?) and saving the original. What I'm really sort of curious about is how many different file sizes people save in and if they keep file directories for each size or lump them all together. Hope you're all having some relaxing holidays! Perian SullyCollection Database and Records AdministratorJudah L. Magnes Museum2911 Russell StreetBerkeley, CA 94705(510) 549-6950 ext. 335--- You are currently subscribed to mcn_mcn-l as: m...@concretecomputing.com To unsubscribe send a blank email to leave-mcn_mcn-l-12800...@listserver.americaneagle.com --- You are currently subscribed to mcn_mcn-l as: akes...@imj.org.il To unsubscribe send a blank email to leave-mcn_mcn-l-12800...@listserver.americaneagle.com --- You are currently subscribed to mcn_mcn-l as: rlancefi...@mail.wesleyan.edu To unsubscribe send a blank email to leave-mcn_mcn-l-12800...@listserver.americaneagle.com
Re: MCN-L Digitization procedures
Re: MCN-L Digitization procedures
I have been following this thread with interest. I sense that resolution is being defined by file size. Have I doubled my sensor resolution by interpolating to increase file size, etc.? The answer is no. Suppose I have two image files, 100 MB and 200 MB. The camera was out of focus with the 200MB image. Its effective resolution is probably lower, despite the larger file size. If I store an image as 16 bit rather than 8 bit per pixel per channel, the file size is larger. This doesn't increase resolution. As so forth. Resolution needs to be determined based on measurement, for example, determining a imaging system's MTF (equivalent to slanted edge SFR). If my resolution increases at a cost of increasing image noise, how does this factor in? Evaluating a camera system requires analysis, not just reading specs and looking at file size. Although file size and resolution may correlate, all other things being equal except the number of pixels on the sensor, it is easy to forget this caveat. Furthermore, this caveat is never true in practice. This can only be confirmed by experimentation. After all, new sensors have more pixels for the same sensor area; this is not equivalent to more pixels over a larger sensor area. x-tad-bigger Roy /x-tad-biggerRoy S. Berns, PhD R. S. Hunter Professor in Color Science, Appearance, and Technology Center for Imaging Science - Color Science Building 18 Munsell Color Science Laboratory Rochester Institute of Technology 54 Lomb Memorial Drive Rochester, NY 14623 585-475-2230 Fax: 585-475- Mobile: 585-719-5621 http://www.cis.rit.edu/people/faculty/berns http://www.cis.rit.edu/mcsl/
Re: MCN-L Digitization procedures
Re: MCN-L Digitization procedures
Re: MCN-L Digitization procedures
Mike, May I ask what application you are using to create the each derivative on the fly?Angela -Original Message-From: Mike Rippy [mailto:mri...@ima-art.org]Sent: Friday, January 06, 2006 9:25 AMTo: mcn-l@mcn.eduSubject: Re: MCN-L Digitization procedures Oh, by the way.Our plan here for our collection photography is to store theraw file, create a master tif file (that has been corrected for dust, color, etc.)and from that make various jpg derivitives (as needed). However, do to storage space limitations, we are considering using a new system thatuses an application togenerate derivatives on "the fly" to be delivered to our users. Saving the cost of storing each derivative file. We also keep each file seperated in a folder for that file type, raw, tif, jpg_screen, jpg_thumb. Be sure to pay close attention to you naming conventions also, http://www.tasi.ac.uk/advice/creating/filenaming.html. This is also covered in the National Archives guidelines. Mike. m...@concretecomputing.com 12/27/2005 9:54 PM There's probably no perfect way to store images on a filesystem, so maybe it should just come down to personal preference. Unless you need specific security settings--for example, so some people can see/edit some files but not others. In that case, you might want to build the arrangement to mirror the security arrangement, which will make setup easier, and corrections a lot easier. There might also be other factors like that, that I'm not thinking of. Anyone else?The "right" way to store images is in some kind of databasing system that keeps image metadata alongside the image files so that you can always find them again by working your way down a hierarchical tree (bad but demonstrative example: Paintings--19th Century--Impressionism--American--Cassatt, Mary--The Cup of Tea) or by searching according to subject, artist, media, title, etc. It's hard to impossible to duplicate that with directories on disk and maintain it reliably. These systems go all the way from $0 to high six figures in cash, and take significant effort and time to implement and maintain.good luck,MattPerian Sully wrote: Hi all: I'm currently developing our digitization procedures and I was wondering what other institutions do to organize their content. I'm planning on photographing identification database images in a fairly high resolution jpg and photograph in RAW for publication-quality. Once the images are downloaded, I'll be processing them in small, medium and large dpi (72/150/?) and saving the original. What I'm really sort of curious about is how many different file sizes people save in and if they keep file directories for each size or lump them all together. Hope you're all having some relaxing holidays! Perian SullyCollection Database and Records AdministratorJudah L. Magnes Museum2911 Russell StreetBerkeley, CA 94705(510) 549-6950 ext. 335--- You are currently subscribed to mcn_mcn-l as: m...@concretecomputing.com To unsubscribe send a blank email to leave-mcn_mcn-l-352062...@listserver.americaneagle.com --- You are currently subscribed to mcn_mcn-l as: ang...@vtls.com To unsubscribe send a blank email to leave-mcn_mcn-l-12800...@listserver.americaneagle.com --- You are currently subscribed to mcn_mcn-l as: rlancefi...@mail.wesleyan.edu To unsubscribe send a blank email to leave-mcn_mcn-l-12800...@listserver.americaneagle.com
Re: MCN-L Digitization procedures
Re: MCN-L Digitization procedures
Re: MCN-L Digitization procedures
We are in the early stages of implementing Luna Insight for this purpose. mri...@ima-art.org 1/6/2006 12:00:14 PM The list I provided isnt exhaustive. There are a lot of various approaches and applications that can be used to manage digital files. And can be used at varous skill levels. If others have opinions of software that would work well in a workflow, please provide them. tarnauto...@speakeasy.net 1/6/2006 10:46 AM I am surprised that no-one is looking into Adobe (Version) Cue. On Jan 6, 2006, at 6:44 AM, Mike Rippy wrote: We havent purchased a system yet. We are still investigating different Digital Asset Management systems. Most of them have a way of creating derivatives as needed. I am not endorsing these products. Just letting you know of the systems I have heard of. http://www.artesiatech.com/html/artesia_for_dam.html http://www.clearstorysystems.com/ and I believe the lower cost products do as well: http://www.extensis.com/en/products/asset_management/product_information.jsp?id=prod60022 http://www.canto.com/ List of Image Management Systems (Feb 2005) from TASI: http://www.tasi.ac.uk/advice/delivering/ims-software.html Matt from concrete computing can probably give you some insight as well. And a more up to date selection. He posted the first reply to this topic. And as he said, These systems go all the way from $0 to high six figures in cash, and take significant effort and time to implement and maintain. (my emphasis). Mike. ang...@vtls.com 1/6/2006 9:26 AM Mike, May I ask what application you are using to create the each derivative on the fly?Angela -Original Message-From: Mike Rippy [mailto:mri...@ima-art.org]Sent: Friday, January 06, 2006 9:25 AMTo: mcn-l@mcn.eduSubject: Re: MCN-L Digitization procedures Oh, by the way. Our plan here for our collection photography is to store the raw file, create a master tif file (that has been corrected for dust, color, etc.) and from that make various jpg derivitives (as needed). However, do to storage space limitations, we are considering using a new system that uses an application to generate derivatives on the fly to be delivered to our users. Saving the cost of storing each derivative file. We also keep each file seperated in a folder for that file type, raw, tif, jpg_screen, jpg_thumb. Be sure to pay close attention to you naming conventions also, http://www.tasi.ac.uk/advice/creating/filenaming.html. This is also covered in the National Archives guidelines. Mike. m...@concretecomputing.com 12/27/2005 9:54 PM There's probably no perfect way to store images on a filesystem, so maybe it should just come down to personal preference. Unless you need specific security settings--for example, so some people can see/edit some files but not others. In that case, you might want to build the arrangement to mirror the security arrangement, which will make setup easier, and corrections a lot easier. There might also be other factors like that, that I'm not thinking of. Anyone else?The right way to store images is in some kind of databasing system that keeps image metadata alongside the image files so that you can always find them again by working your way down a hierarchical tree (bad but demonstrative example: Paintings--19th Century--Impressionism--American--Cassatt, Mary--The Cup of Tea) or by searching according to subject, artist, media, title, etc. It's hard to impossible to duplicate that with directories on disk and maintain it reliably. These systems go all the way from $0 to high six figures in cash, and take significant effort and time to implement and maintain.good luck,MattPerian Sully wrote:Hi all: I'm currently developing our digitization procedures and I was wondering what other institutions do to organize their content. I'm planning on photographing identification database images in a fairly high resolution jpg and photograph in RAW for publication-quality. Once the images are downloaded, I'll be processing them in small, medium and large dpi (72/150/?) and saving the original. What I'm really sort of curious about is how many different file sizes people save in and if they keep file directories for each size or lump them all together. Hope you're all having some relaxing holidays! Perian SullyCollection Database and Records AdministratorJudah L. Magnes Museum2911 Russell StreetBerkeley, CA 94705(510) 549-6950 ext. 335 --- You are currently subscribed to mcn_mcn-l as: m...@concretecomputing.com To unsubscribe send a blank email to leave-mcn_mcn-l-12800...@listserver.americaneagle.com --- You are currently subscribed to mcn_mcn-l as: ang...@vtls.com To unsubscribe send a blank email to leave-mcn_mcn-l-12800...@listserver.americaneagle.com--- You are currently subscribed to mcn_mcn-l as: mri...@ima-art.org To unsubscribe send a blank email to leave-mcn_mcn-l-12800...@listserver.americaneagle.com --- You are currently subscribed to mcn_mcn-l as: tarnauto...@speakeasy.net
Re: MCN-L Digitization procedures
To add to the list: DSpace (www.dspace.org) for institutions that have at least one technologically skilled support person.By all means, do include my suggestion if you see fit. Since most image editing and processing is done in Photoshop (at least in my organization), Version Cue fits right into it.On Jan 6, 2006, at 9:00 AM, Mike Rippy wrote:The list I provided isnt exhaustive. There are a lot of various approaches and applications that can be used to manage digital files. And can be used at varous skill levels. If others have opinions of software that would work well in a workflow, please provide them. tarnauto...@speakeasy.net 1/6/2006 10:46 AM I am surprised that no-one is looking into Adobe (Version) Cue.On Jan 6, 2006, at 6:44 AM, Mike Rippy wrote: We havent purchased a system yet. We are still investigating different Digital Asset Management systems. Most of them have a way of creating derivatives as needed. I am not endorsing these products. Just letting you know of the systems I have heard of. http://www.artesiatech.com/html/artesia_for_dam.html http://www.clearstorysystems.com/ and I believe the lower cost products do as well: http://www.extensis.com/en/products/asset_management/product_information.jsp?id=prod60022 http://www.canto.com/ List of Image Management Systems (Feb 2005) from TASI: http://www.tasi.ac.uk/advice/delivering/ims-software.html Matt from concrete computing can probably give you some insight as well. And a more up to date selection. He posted the first reply to this topic. And as he said, "These systems go all the way from $0 to high six figures in cash, and take significant effort and time to implement and maintain." (my emphasis). Mike. ang...@vtls.com 1/6/2006 9:26 AM Mike, May I ask what application you are using to create the each derivative on the fly?Angela -Original Message-From: Mike Rippy [mailto:mri...@ima-art.org]Sent: Friday, January 06, 2006 9:25 AMTo: mcn-l@mcn.eduSubject: Re: MCN-L Digitization procedures Oh, by the way. Our plan here for our collection photography is to store the raw file, create a master tif file (that has been corrected for dust, color, etc.) and from that make various jpg derivitives (as needed). However, do to storage space limitations, we are considering using a new system that uses an application to generate derivatives on "the fly" to be delivered to our users. Saving the cost of storing each derivative file. We also keep each file seperated in a folder for that file type, raw, tif, jpg_screen, jpg_thumb. Be sure to pay close attention to you naming conventions also, http://www.tasi.ac.uk/advice/creating/filenaming.html. This is also covered in the National Archives guidelines. Mike. m...@concretecomputing.com 12/27/2005 9:54 PM There's probably no perfect way to store images on a filesystem, so maybe it should just come down to personal preference. Unless you need specific security settings--for example, so some people can see/edit some files but not others. In that case, you might want to build the arrangement to mirror the security arrangement, which will make setup easier, and corrections a lot easier. There might also be other factors like that, that I'm not thinking of. Anyone else?The "right" way to store images is in some kind of databasing system that keeps image metadata alongside the image files so that you can always find them again by working your way down a hierarchical tree (bad but demonstrative example: Paintings--19th Century--Impressionism--American--Cassatt, Mary--The Cup of Tea) or by searching according to subject, artist, media, title, etc. It's hard to impossible to duplicate that with directories on disk and maintain it reliably. These systems go all the way from $0 to high six figures in cash, and take significant effort and time to implement and maintain.good luck,MattPerian Sully wrote: Hi all: I'm currently developing our digitization procedures and I was wondering what other institutions do to organize their content. I'm planning on photographing identification database images in a fairly high resolution jpg and photograph in RAW for publication-quality. Once the images are downloaded, I'll be processing them in small, medium and large dpi (72/150/?) and saving the original. What I'm really sort of curious about is how many different file sizes people save in and if they keep file directories for each size or lump them all together. Hope you're all having some relaxing holidays! Perian SullyCollection Database and Records AdministratorJudah L. Magnes Museum2911 Russell StreetBerkeley, CA 94705(510) 549-6950 ext. 335--- You are currently subscribed to mcn_mcn-l as: m...@concretecomputing.com To unsubscribe send a blank email to leave-mcn_mcn-l-12800...@listserver.americaneagle.com--- You are currently subscribed to mcn_mcn-l as: ang...@vtls.com To unsubscribe send a blank email to leave-mcn_mcn-l-491428...@lists
Re: MCN-L Digitization procedures
Hi Mike, everybody A couple of observations re on the fly derivatives from a techie perspective: 1) I would expect JPEG derivatives, particular if at substantially lower resolution, to be very much smaller than the master TIF, even with TIF compression. Makes me wonder about the exact nature of the storage space limitations you mention. 2) Generating and a derivative on-the-fly implies loading and processing the (very) bulky original file. My instinct is that the I/O and processing burden of doing this is a high price to pay for the small proportion of storage space likely to be saved. Interesting idea tho maybe a compromise could work well. Have a few strategically sized derivatives ready made for 90% of anticipated needs, and have an on-the-fly facility to generate more specialised versions, avoiding the need to store a derivative for every conceivable purpose. I suspect thats the line youre already thinking along. David Marsh -Original Message- From: Mike Rippy [mailto:mri...@ima-art.org] Sent: Friday, January 06, 2006 6:25 AM To: mcn-l@mcn.edu Subject: Re: MCN-L Digitization procedures Oh, by the way.Our plan here for our collection photography is to store theraw file, create a master tif file (that has been corrected for dust, color, etc.)and from that make various jpg derivitives (as needed). However, do to storage space limitations, we are considering using a new system thatuses an application togenerate derivatives on the fly to be delivered to our users. Saving the cost of storing each derivative file === David Marsh System Administrator H.R. MacMillan Space Centre 1100 Chestnut Street, Vancouver, BC V6J 3J9 E dma...@hrmacmillanspacecentre.com T (604) 738 7827 ext. 255 C (604) 813 9667 === --- You are currently subscribed to mcn_mcn-l as: rlancefi...@mail.wesleyan.edu To unsubscribe send a blank email to leave-mcn_mcn-l-12800...@listserver.americaneagle.com
Re: MCN-L Digitization procedures
That sounds like what we do with VITAL. We use JPEG2000 or MrSID high resolution derivatives from the archival tiffs. Then, "on the fly" we recreate the image withjpeg tiles in our high-resolution image navigator (web application) for public search and display. This provides detailed displayofthe images, withoutthe heavy I/O and processing burden. Angela -Original Message-From: David Marsh [mailto:dpma...@telus.net]Sent: Friday, January 06, 2006 1:17 PMTo: mcn-l@mcn.eduSubject: RE: MCN-L Digitization procedures Hi Mike, everybody A couple of observations re on the fly derivatives from a techie perspective: 1) I would expect JPEG derivatives, particular if at substantially lower resolution, to be very much smaller than the master TIF, even with TIF compression. Makes me wonder about the exact nature of the storage space limitations you mention. 2) Generating and a derivative on-the-fly implies loading and processing the (very) bulky original file. My instinct is that the I/O and processing burden of doing this is a high price to pay for the small proportion of storage space likely to be saved. Interesting idea tho maybe a compromise could work well. Have a few strategically sized derivatives ready made for 90% of anticipated needs, and have an on-the-fly facility to generate more specialised versions, avoiding the need to store a derivative for every conceivable purpose. I suspect thats the line youre already thinking along. David Marsh -Original Message-From: Mike Rippy [mailto:mri...@ima-art.org] Sent: Friday, January 06, 2006 6:25 AMTo: mcn-l@mcn.eduSubject: Re: MCN-L Digitization procedures Oh, by the way.Our plan here for our collection photography is to store theraw file, create a master tif file (that has been corrected for dust, color, etc.)and from that make various jpg derivitives (as needed). However, do to storage space limitations, we are considering using a new system thatuses an application togenerate derivatives on "the fly" to be delivered to our users. Saving the cost of storing each derivative file === David Marsh System Administrator H.R. MacMillan Space Centre 1100 Chestnut Street, Vancouver, BC V6J 3J9 E dma...@hrmacmillanspacecentre.com T (604) 738 7827 ext. 255 C (604) 813 9667 === --- You are currently subscribed to mcn_mcn-l as: ang...@vtls.com To unsubscribe send a blank email to leave-mcn_mcn-l-12800...@listserver.americaneagle.com --- You are currently subscribed to mcn_mcn-l as: rlancefi...@mail.wesleyan.edu To unsubscribe send a blank email to leave-mcn_mcn-l-12800...@listserver.americaneagle.com
Re: MCN-L Digitization procedures
Re: MCN-L Digitization procedures
Title: Re: MCN-L Digitization procedures When you are considering your management system, you need to consider what it is to do. Some work best as delivering a library of information, these have the metadata, one set image size and provide easy search technique such as a museums out reach/ education groups might use on your web site and in the museum itself. And example of this type is Lunas Insight or your own web developed system. Others have been developed for production and publication workflow such as your promotional, PR, exhibitors etc, might need that can deliver the right size image image for a unique use with the critical data such as copyright, version control, and past use, as well as people, activities or concepts etc. Artesia () is an en example of this. Then there are the Collection management systems, which may or may not require digital images. In the medium price range, there are those systems that are trying to do both such as Cantos and Extensiss programs. Interestingly Extensiss Portfolio offers you the option to save your screen images and speed up imaging. It is also a nice safety measure as these images are saved somewhere other than where your originals are. I recommend that you think of the components of the system, define them and then see which programs might provide them. The components might be Cataloger could be in Access, FMP, or Portfolio, Adobe Publisher independent web development, Luna, Portfolo/Canto Presentation - for lectures etc - Power Point, Luna Distribution could be Artesia, adding on Adobe Image Server to your publisher as eMotion does http://www.emotion.com/ . It has become a Corbis company I see very interesting. Anyway there are several that us the Image server to deliver formats on the fly. Digital Repository Dspace I also support Mikes recommendation for using TASI and NARA, though TASI is much easier to read. -- Trudy Levy Consultant for Digital Imaging Projects Image Integration 415 750 1274 http://www.DIG-Mar.com Membership Chair, Visual Resources Association http://vraweb.org Images are information - Manage them On 1/6/06 10:16 AM, David Marsh dpma...@telus.net wrote: Hi Mike, everybody A couple of observations re on the fly derivatives from a techie perspective: 1) I would expect JPEG derivatives, particular if at substantially lower resolution, to be very much smaller than the master TIF, even with TIF compression. Makes me wonder about the exact nature of the storage space limitations you mention. 2) Generating and a derivative on-the-fly implies loading and processing the (very) bulky original file. My instinct is that the I/O and processing burden of doing this is a high price to pay for the small proportion of storage space likely to be saved. Interesting idea tho maybe a compromise could work well. Have a few strategically sized derivatives ready made for 90% of anticipated needs, and have an on-the-fly facility to generate more specialised versions, avoiding the need to store a derivative for every conceivable purpose. I suspect thats the line youre already thinking along. David Marsh -Original Message- From: Mike Rippy [mailto:mri...@ima-art.org] Sent: Friday, January 06, 2006 6:25 AM To: mcn-l@mcn.edu Subject: Re: MCN-L Digitization procedures Oh, by the way. Our plan here for our collection photography is to store the raw file, create a master tif file (that has been corrected for dust, color, etc.) and from that make various jpg derivitives (as needed). However, do to storage space limitations, we are considering using a new system that uses an application to generate derivatives on the fly to be delivered to our users. Saving the cost of storing each derivative file === David Marsh System Administrator H.R. MacMillan Space Centre 1100 Chestnut Street, Vancouver, BC V6J 3J9 E dma...@hrmacmillanspacecentre.com T (604) 738 7827 ext. 255 C (604) 813 9667 === --- You are currently subscribed to mcn_mcn-l as: tr...@dig-mar.com To unsubscribe send a blank email to leave-mcn_mcn-l-12799...@listserver.americaneagle.com --- You are currently subscribed to mcn_mcn-l as: rlancefi...@mail.wesleyan.edu To unsubscribe send a blank email to leave-mcn_mcn-l-12800...@listserver.americaneagle.com
Re: MCN-L Digitization procedures
Title: Re: MCN-L Digitization procedures That is not quite what programs such as Artesia or those with the image server do, though it is a great delivery system for the web. These programs, which focus on distributing image files, actually will deliver a Tif or a jpef of a certain size as required by the user, usually for a publishing purpose. It comes from the Reuse of Asset goals that originally drove this software development. -- Trudy Levy Consultant for Digital Imaging Projects Image Integration 415 750 1274 http://www.DIG-Mar.com Membership Chair, Visual Resources Association http://vraweb.org Images are information - Manage them On 1/6/06 10:45 AM, Angela Merchant ang...@vtls.com wrote: That sounds like what we do with VITAL. We use JPEG2000 or MrSID high resolution derivatives from the archival tiffs. Then, on the fly we recreate the image with jpeg tiles in our high-resolution image navigator (web application) for public search and display. This provides detailed display of the images, without the heavy I/O and processing burden. Angela --- You are currently subscribed to mcn_mcn-l as: rlancefi...@mail.wesleyan.edu To unsubscribe send a blank email to leave-mcn_mcn-l-12800...@listserver.americaneagle.com
MCN-L Digitization procedures
Hi all: I'm currently developing our digitization procedures and I was wondering what other institutions do to organize their content. I'm planning on photographing identification database images in a fairly high resolution jpg and photograph in RAW for publication-quality. Once the images are downloaded, I'll be processing them in small, medium and large dpi (72/150/?) and saving the original. What I'm really sort of curious about is how many different file sizes people save in and if they keep file directories for each size or lump them all together. Hope you're all having some relaxing holidays! Perian SullyCollection Database and Records AdministratorJudah L. Magnes Museum2911 Russell StreetBerkeley, CA 94705(510) 549-6950 ext. 335 --- You are currently subscribed to mcn_mcn-l as: rlancefi...@mail.wesleyan.edu To unsubscribe send a blank email to leave-mcn_mcn-l-12800...@listserver.americaneagle.com
Re: MCN-L Digitization procedures
There's probably no perfect way to store images on a filesystem, so maybe it should just come down to personal preference. Unless you need specific security settings--for example, so some people can see/edit some files but not others. In that case, you might want to build the arrangement to mirror the security arrangement, which will make setup easier, and corrections a lot easier. There might also be other factors like that, that I'm not thinking of. Anyone else? The "right" way to store images is in some kind of databasing system that keeps image metadata alongside the image files so that you can always find them again by working your way down a hierarchical tree (bad but demonstrative example: Paintings--19th Century--Impressionism--American--Cassatt, Mary--The Cup of Tea) or by searching according to subject, artist, media, title, etc. It's hard to impossible to duplicate that with directories on disk and maintain it reliably. These systems go all the way from $0 to high six figures in cash, and take significant effort and time to implement and maintain. good luck, Matt Perian Sully wrote: Hi all: I'm currently developing our digitization procedures and I was wondering what other institutions do to organize their content. I'm planning on photographing identification database images in a fairly high resolution jpg and photograph in RAW for publication-quality. Once the images are downloaded, I'll be processing them in small, medium and large dpi (72/150/?) and saving the original. What I'm really sort of curious about is how many different file sizes people save in and if they keep file directories for each size or lump them all together. Hope you're all having some relaxing holidays! Perian Sully Collection Database and Records Administrator Judah L. Magnes Museum 2911 Russell Street Berkeley, CA 94705 (510) 549-6950 ext. 335 --- You are currently subscribed to mcn_mcn-l as: m...@concretecomputing.com To unsubscribe send a blank email to leave-mcn_mcn-l-12800...@listserver.americaneagle.com matt 8.vcf (missing attachment) --- You are currently subscribed to mcn_mcn-l as: rlancefi...@mail.wesleyan.edu To unsubscribe send a blank email to leave-mcn_mcn-l-12800...@listserver.americaneagle.com
