Hermanland » Computing

Zenphoto v1.3.1.2 only partly fixed security bug.

herman — Mon, 06 Sep 2010 12:23:53 +0000

There is a security bug in Zenphoto v1.3.1.1. For user granted with “Albums” rights, the user can view his managed albums but cannot update the album if the edit checkbox of the managed album is unchecked. It is correct. However, whenever the user’s password is updated by the administrator or even by the user himself, the edit checkbox is auto checked by the system, hence allowing the user to update his managed album which he is not supposed to be allowed to do so. Zenphoto v1.3.1.2 seems to fix the security bug if the user is not assigned to any user group. If user is assigned to user group, the security bug still exists. So, be careful.

XMP aux:Lens is tag or attribute?

herman — Thu, 02 Sep 2010 12:16:50 +0000

Which is right and which is wrong? I cannot find the exact answer from Adobe XML specification document.

In ExifTool documentation about XMP aux namespace, aux:Lens is defined as tag rather than attribute. However, IDimager generates aux:Lens as attribute rather than tag in the embedded XMP block in jpg image file, causing Zenphoto unable to extract the value of aux:Lens. After I perform a dummy update to the same image file, Zenphoto is able to extract the value of aux:Lens because I found aux:Lens now appears as tag in the embedded XMP block. Funny enough, ExifTool is able to parse the XMP with aux:Lens as attribute and writes back the XMP block with aux:Lens as tag.

aux:Lens generated by IDimager as attribute

 xmlns:aux="http://ns.adobe.com/exif/1.0/aux/"
                 rdf:about=""
                 aux:Lens="Pentax smc PENTAX-M 40mm F2.8 sn 5145745 (PK)"
/>

aux:Lens generates by ExifTool as tag

 xmlns:aux="http://ns.adobe.com/exif/1.0/aux/" rdf:about="">
 >
   Pentax smc PENTAX-M 40mm F2.8 sn 5145745 (PK)
 >
>

As a follow up of my finding, I just found Adobe Lightroom version 3.0 generates aux:Lens as tag rather than attribute, meaning Lightroom version 3.0 behaves the same way as ExifTool. My test steps were similar as above but using raw file with XMP sidecar file rather than jpg file with embedded XMP block so that I dont need to extract the XMP from the jpg file but I believe the principle should be the same. I just updated the XMP sidecar file (that was generated from IDimager) with Lightroom. Then, I found that the aux:Lens was redefined as tag rather than attribute.

Folder state

herman — Fri, 30 Jul 2010 15:14:08 +0000

Considering my DAM workflow, I can see the folder holding the media files can be under following state:

Open, Full, Computed, Reviewing, Prepared, Archived, Re-working, Trash

How to verify the backup tool really performing data verification?

herman — Mon, 26 Jul 2010 13:42:55 +0000

Although some backup tools claim data verification is performed to ensure data is copied correctly, most tools do not disclose how the data verification is performed. How do the tools ensure the file content copied to the backup media is exactly the same as the original one? Some tools state they use binary comparison or checksum or temporary folder but I cannot think of any way to verify the claim that data verification is really performed. Does anyone know a way to do so? To release my concern, I compute checksum to the source folder before performing a backup and then run the same checksum againist the destination folder after the backup.

Life cycle of a DAM folder

herman — Mon, 22 Feb 2010 12:40:13 +0000

I am wondering what is the life cycle for a folder in the context of Digital Asset Management. In line with the bucket and additive backup concept, I see a bucket in a HDD undergoes following life cycle.

Open - The bucket is available for adding new files. Folder in other status is always full as a backup bucket and no new files should be added to the folder.
Meta in Review – Meta data is under review.
Image in Review – Hash total was generated and the photo or video images are under review.
Closed - The bucket was closed for any further update and is ready to backup to read-only media e.g. DVD.
Re-open - The closed bucket is re-opened for updating.

Hash total is a text file kept immediately under a bucket folder listing all the file name, attribute and checksum. Hash total is a digital signature to the bucket folder allowing to automatically detect any changes in content in the folder.

Which software to create the digest text file in batch?

herman — Mon, 08 Feb 2010 04:08:13 +0000

There are many software to create the digest text file for multiple files in batch. Following features help to manage to manage a large photo portfolio more effective.

Selectively update the digest text file just for the changed or new photo only because I dont want to visually verify the other old photos again because they are too many.
Able to perform digest verification on read only media e.g. DVD.
Portable application so that I can perform the digest verification any where any time.
Consider file modified attribute and file modified datetime.
Keep should-be checksum, file attributes in digest file and show it along with actual value in the verification result.

How to verify a big collection of photo

herman — Wed, 02 Dec 2009 15:02:00 +0000

When I have more than 20,000 photo in my collection, I start to wonder how I can ensure all of them are still being kept in the storage media properly. All media e.g. hard disk or DVD will be aging and I may find some photos cannot be displayed properly when I open them some day in the future. This will happen although no one can tell exactly when. Regular data backup will not help because backing up rubbish gets rubbish. My solution is to have the computer automatically create a digest text file containing a list of order pair of file name and checksum for the photos in my collection bucket. And then, I visually verify these photos. It is tricky. Visually verifying photos and then creating digest is still not the safest. Then, I can have the computer to automatically verify the photos regularly. Whenever I need to copy or move the photos across partition, I also use a special tool with checksum verification to do so.

Versioning affects label item count in IDimager

herman — Thu, 24 Sep 2009 13:02:00 +0000

What will happen when 2 image files with different keywords are brought together to form a version set? In Idimager, the labels are merged into the main version that can have label assigned while the other version cannot have. For example, the image A has 2 object label apple and fruit and the image B has 2 object label banana and fruit. The object label item count is then 2. The apple label item count is 1 and the banana label item count is 1 and the fruit label item count is 2. After the 2 images forming a version set with image A as main version, the object label item count and fruit label item count are both decreased to 1. The apple label item count and banana label item count both remain unchanged. The label merging mechanism do not apply to auto label e.g. import session and that is why I found the auto label item count always decreasing after versioning as stated in my previous post.

Where is my meta data kept ?

herman — Tue, 15 Sep 2009 14:40:00 +0000

After I added the meta data for my image file, where is the data kept? It may just be kept in the database, the XMP sidecar file or embedded in IPTC block or XMP block within the image file. Before I adapt a new tool to maintain meta data, I need to find out from where the tool will import the meta and to where the tool will keep the meta. Adobe PS family software tends to use XMP sidecar for proprietary raw and even jpg. For dng file, they keep the meta in the embedded XMP block. Because I prefer to keep the meta within the image file, I use PS Bridge purely as a media browser and avoid even doing any rating there. I also turn on the ‘merge XMP’ option in file handling in Image Ingestor so that the batch meta will be inserted to the XMP block within the image file. From the product web page, I found quote “A little problem that this introduced is that there’s no way to prevent generation of XMP sidecars. This will be fixed.” Therefore, I need to manual delete the XMP sidecar files. After ingestion, I keep my practice to maintain the meta always from Idimager because the tool maps its XMP based catalog to the EXIF, IPTC and XMP embedded block within the image file for maximum compatibility.

Wikka wiki 1.2 and UTF-8

herman — Sun, 13 Sep 2009 15:09:00 +0000

Wikka wiki 1.2 is available. The major enhancements to me are the support of table wiki markup and the nice looking ‘Light’ template. Same as previous version, I found the new version also stores the UTF-8 encoded non ascii characters as numeric reference e.g. & # 915; & # 917; & # 925; & # 917; & # 931; & # 921; & # 931;
I need to apply the hack as I did for previous version to correct it. However, I found the search function to the non ascii characters did not work after the patch but there was no such problem with previous version with the same patch. Also, I just found there is a hack that may correct the search function but there seems to have some side effort but I have not tried this hack yet.