List Info

Thread: Re: Keeping Co-Master files




Re: Keeping Co-Master files
user name
2007-03-11 20:55:04
Indeed, Hail the Mighty Metadata.....
 
But we rarely work with  collections that are identical in size or that end up perfectly aligned as you turn pages of a sketchbook,  journal, album etc.  We also use different digitisation devices and use them with quite different set ups and lighting/polarising conditions.  This would generate  quite a number of calibration/cropping reference images over time.
 
We have also pondered whether to shoot the targets at the beginning of a session/collection only, ; rather than include them in each image but we feel it much better to keep them inside the individual image.  There has been some good discussion regarding internal vs external (device level) calibration targets already.
 
Linking to a single calibration shot could work for all in house use (e.g. our own web and print designers)  but  we distribute many images to external users (media,  publishers/researchers TV/documentary etc) and maintaining a metadata link would be very difficult. 
 
Thanks
 
Scott
 
Scott Wajon
Coordinator
Imaging Services
State Library of New South Wales
 
swajonsl.nsw.gov.au">swajonsl.nsw.gov.au

>>> tblakeBPL.ORG 12/03/2007 12:36:16 pm >>>

Another approach that could save even more file real = estate might be to use administrative metadata to link to a single shot = of your targets to batches of production shots. If your set up is = consistent, the targets could be applied to every image captured during = any relevant session.

Metadata wins again.

-Tom Blake




-----Original Message-----
From: IMAGELIB on behalf of Scott Wajon
Sent: Sun 3/11/2007 6:14 PM
To: IMAGELIBLISTSERV.ARIZONA.EDU
Subject: Keeping Co-Master files

This is a MIME message. If you are reading this text, you may want = to
consider changing to a mail reader or gateway that understands how = to
properly handle MIME multipart messages.

--=3D__PartFEDA4258.0__=3D
Content-Type: text/plain; charset=3DUS-ASCII
Content-Transfer-Encoding: 7bit

Hi,

It seems a common digital archiving practice to keep  the = uncropped,
uncompressed Archival Master file as well as a cropped (colour bars,
tags
out etc) CoMaster or Publication File.
Generally speaking the Co Master would be about 80% of the file size
(after
cropping out unwanted bits) and therefore represents a very
significant
storage issue if you are saving both files ( as well as = derivatives).

Here is another approach,  one that has been suggested by our = IT
people......

What about ; keeping information about the crop as part of the = metadata
for
each file - i.e. recording and storing the coordinates of each = corner
of the
required crop and then using this information to automate the
production of
a cropped rendition ( could be a derivative at any pixel dimensions) = on
the
fly,  as requested.

Photoshop can show in the Info Palette,  the top left hand = coordinate
of the
crop marquee and the x an y pixel length of the sides of the crop
marquee.
This gives enough information to reproduce the crop each time and
requires
no real storage space

You could record this manually (perhaps into a spreadsheet initially
then
into another program/plugin that works with your Digital Asset
Management
System,  e.g. Imagemagic)  .  Crop info could be recorded = at time of
QC,
just before ingestion into the DAM,  by doing a "practice = crop" but
then
not applying it to the Master.

I know you can save and load crops as selections or layers or alpha
channels
in Photoshop but this brings a whole new set of issues about = archiving
layered and proprietary files,  as opposed to plain old Tiffs = and
utilising
metadata,  so we are not interested in going down this road.

Look forward to comments on the approach,  even if you don't = have
practical
experience in this technique

Scott Wajon

Scott Wajon
Coordinator
Imaging Services
State Library of New South Wales

swajonsl.nsw.gov.au



Dig in at Australia's most exciting research library http://www.atmitchell.com
-------------------------------------------------------------------------= ---------------------------
-------------------------------------------------------------------------= ---------------------------
///Please note/// This email and any attachments to it are privileged = and confidential. If you are not the intended recipient, please notify = the sender and delete it. The contents of this email are not given or = endorsed by the State Library of New South Wales unless otherwise = indicated by an authorised officer of the Library. Copyright law may = also apply to the contents of this email.


&lt;<<< GWAVASIG >>&gt;>
--=3D__PartFEDA4258.0__=3D
Content-Type: text/html; charset=3DISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Description: HTML

<HTML><;HEAD>
&lt;META http-equiv=3D3DContent-Type content=3D3D"text/html; = charset=3D3Dus-ascii">
<META content=3D3D"MSHTML 6.00.2900.2769" = name=3D3DGENERATOR>;</HEAD&gt;
<BODY style=3D3D"MARGIN: 4px 4px 1px; FONT: 12pt = Arial">
<DIV>;Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>It seems a common digital archiving practice to = keep&nbsp; the =3D
uncropped,<BR&gt;uncompressed Archival Master file as well as a = cropped =3D
(colour bars,&nbsp; tags<BR>out etc) CoMaster or Publication = File. =3D
<BR>Generally speaking the Co Master would be about 80% of the = file size =3D
(after<BR>cropping out unwanted bits) and therefore represents a = very =3D
significant<BR>storage issue if you are saving both files ( as = well as =3D
derivatives).</DIV>
&lt;DIV>&amp;nbsp;<;/DIV>
&lt;DIV>Here is another approach,&amp;nbsp; one that has been = suggested by our =3D
IT<BR>people......</DIV>
&lt;DIV>&amp;nbsp;<;/DIV>
&lt;DIV>What about&nbsp; keeping information about the crop as = part of the =3D
metadata for<BR&gt;each file - i.e. recording and storing the = coordinates of =3D
each corner of the<BR&gt;required crop and then using this = information to =3D
automate the production of<BR&gt;a cropped rendition ( could be a = derivative =3D
at any pixel dimensions) on the<BR&gt;fly,&;nbsp; as = requested.</DIV>;
<DIV&gt;&nbsp;</DIV&gt;
<DIV&gt;Photoshop can show in the Info Palette,&amp;nbsp; the top = left hand =3D
coordinate of the<BR&gt;crop marquee and the x an y pixel length of = the sides =3D
of the crop marquee.&lt;BR>This gives enough information to reproduce = the =3D
crop each time and requires&lt;BR>no real storage = space</DIV>
<;DIV>&amp;nbsp;</DIV>
&lt;DIV>You could record this manually (perhaps into a spreadsheet = initially =3D
then&lt;BR>into another program/plugin that works with your Digital = Asset =3D
Management<BR&gt;System,&amp;nbsp; e.g. Imagemagic)&nbsp; = .&nbsp; Crop info could =3D
be recorded at time of QC,<BR&gt;just before ingestion into the = DAM,&nbsp; by =3D
doing a "practice crop" but then<BR>not applying it to = the Master.<;/DIV>
&lt;DIV>&amp;nbsp;&lt;/DIV>
<DIV>I know you can save and load crops as selections or layers or = alpha =3D
channels<BR>;in Photoshop but this brings a whole new set of issues = about =3D
archiving<BR&gt;layered and proprietary files,&;nbsp; as opposed = to plain old =3D
Tiffs and utilising&lt;BR>metadata,&;nbsp; so we are not = interested in going =3D
down this road.</DIV>
<;DIV>&amp;nbsp;</DIV>
&lt;DIV>Look forward to comments on the approach,&amp;nbsp; even if = you don't =3D
have practical&lt;BR>experience in this technique&lt;/DIV>
<DIV>;&nbsp;</DIV>;
<DIV&gt;Scott Wajon</DIV>
<;DIV>&amp;nbsp;</DIV>
&lt;DIV>Scott Wajon<BR>Coordinator<BR>Imaging = Services&lt;BR>State Library of =3D
New South Wales</DIV>
<;DIV>&amp;nbsp;</DIV>
&lt;DIV>&lt;A href=3D3D"sl.nsw.gov.au"'>mailto:swajonsl.nsw.gov.au"= ;>swajonsl.nsw.gov.au</A&gt;</DIV&gt;=3D
</BODY>&lt;/HTML>

<p>
<br>
<br>
Dig in at Australia's most exciting research library http://www.atmitchell.com = <br>
-------------------------------------------------------------------------= ---------------------------<br>
-------------------------------------------------------------------------= ---------------------------<br>
///Please note/// This email and any attachments to it are privileged = and confidential. If you are not the intended recipient, please notify = the sender and delete it. The contents of this email are not given or = endorsed by the State Library of New South Wales unless otherwise = indicated by an authorised officer of the Library. Copyright law may = also apply to the contents of this email.<br>
<br>
<br>
<<<<; GWAVASIG >>&gt;>
<p>
--=3D__PartFEDA4258.0__=3D--

[1]

about | contact  Other archives ( Real Estate discussion Medical topics )