Aperture Import Folder Structure
I have successfully imported about 11,000 referenced images from my Aperture library into Capture One 8.2.1. After the import, my Aperture projects show up as Capture One collections and my folders show up in a folder tree. The problem is that when I import a brand new set of images into a new folder, the folder shows up in a separate tree that looks identical except for a few icons. I really don't want to have to separate folder tree but rather add on to my existing tree. I'll try indicate what I am seeing below? Thank you.
v <icon> Macintosh HD
v <icon> Users
v <icon> Jack
v <icon>Desktop
v <icon> Images
v <icon>Nikon D300
<icon>2015-04-18 <- new folder added but want in tree below
v <icon> Macintosh HD
v <icon> Users
v <icon> Jack
v <icon>Desktop
v <icon> Images
v <icon>Nikon D300
<icon>2005-01-01 <- folder that I imported
<icon>2005-01-02 <- folder that I imported
... many more folders imported from Aperture ...
0
-
I am afraid I do not get the point yet. Maybe you can post a screenshot? First thought was that you can import to any folder you like. 0 -
How do I post a screenshot? I was going to but couldn't figure out how so I opted to try to reproduce the look. Looking at the Capture One catalog with a hex editor, it appears that file paths that are imported from Aperture are stored a bit differently than from an import which might account for the display of separate trees. 0 -
Join a free online image host such as Photobucket and upload your image/screenshot there and then copy and paste the code in your post here.
The code should start [ img ] and end [ /img ].0 -
[quote="NN635602308421234413UL" wrote:
How do I post a screenshot? I was going to but couldn't figure out how so I opted to try to reproduce the look. Looking at the Capture One catalog with a hex editor, it appears that file paths that are imported from Aperture are stored a bit differently than from an import which might account for the display of separate trees.
I would think that the easiest course of action here would be to ask the question in a Support Case.
It is possible that the Aperture Catalog Ingestion is thought of as a unique "copy" (for whatever reason) and so is intended to be kept separate within the catalogue. I don't know, I'm just speculating on how one might approach such a Transfer of data from one system to another.
Asking those who should certainly know seems to be the best and fastest way to get an answer and perhaps a way to work with how you want things to be in the future.
HTH.
Grant0 -
Following is a screenshot. The first folder tree contains a new folder that I imported directly into Capture One. The second folder tree is the one created by the Aperture import. Notice that the icons are plain in the second tree but look like standard Mac icons in the first tree.
https://www.flickr.com/photos/22959801@N05/17202487531/
If the image doesn't make it, this is the URL:0 -
I did find a workaround for the duplicate folder trees although it involves quite a bit of work. If I go to the first folder tree, right click, "Add Folder...", and choose one of the imported folders then Capture One will add the folder to the first tree. I can then select the same folder in the second tree, select all of the images in that folder, drag them to the same folder in the first tree, and delete the folder from the second tree. All adjustments, etc. picked up from Aperture by Capture One are retained with the images.
I realize that the Aperture Import functionality is labeled beta but would like to ask that it be modified to store file paths the same whether from an Aperture Import or from a new import (or however else the problem can be corrected) so as not to create multiple folder trees for what is actually a single physical folder structure. Thank you.0 -
I resolved this issue by modifying the Capture One catalog to store the file path root and path names of paths imported from Aperture similar to how they are stored when new images are imported from a card reader. The catalog is a sqlite3 database so it was simple for me to do (I'm a former software developer). Now I have only a single tree of folders. 0 -
[quote="rjackb" wrote:
I resolved this issue by modifying the Capture One catalog to store the file path root and path names of paths imported from Aperture similar to how they are stored when new images are imported from a card reader. The catalog is a sqlite3 database so it was simple for me to do (I'm a former software developer). Now I have only a single tree of folders.
Worth report a bug to PO? Everyone was/is/would-like-to-be a developer!! No one wants to be Tester - because 'we' are bad ppl - we show developers, that they're wrong 😉
👿0 -
[quote="PaaS" wrote:
[quote="rjackb" wrote:
I resolved this issue by modifying the Capture One catalog to store the file path root and path names of paths imported from Aperture similar to how they are stored when new images are imported from a card reader. The catalog is a sqlite3 database so it was simple for me to do (I'm a former software developer). Now I have only a single tree of folders.
Worth report a bug to PO? Everyone was/is/would-like-to-be a developer!! No one wants to be Tester - because 'we' are bad ppl - we show developers, that they're wrong 😉
👿
Except that in this case as I read it the observed dislike relates to a dedicated free utility put together to help people who wanted to try out Capture One when Apple, in their wisdom, announced that they would stop supporting Aperture.
So any change is, surely, a Feature Enhancement Request and can be proposed as such through the Support Case system.
That woould apply to both the conversion utility an the C1 application.
Hacking database structures is all very well for those with the skill sets to do so but more suited to Open Source activity. It should also, assuming it is not disallowed by the terms of the use licence, be declared whenever techical support is requested for the avoidance of any confusion.
In my opinion.
Grant0 -
[quote="SFA" wrote:
...
Except that in this case as I read it the observed dislike relates to a dedicated free utility put together to help people who wanted to try out Capture One when Apple, in their wisdom, announced that they would stop supporting Aperture.
Sorry, not sure what are you talking about. Based on what is that assumption? If the PO - borrowed (politely said) some mechanism for importing Aperture library - and I as customer paid for C1P - thus the PO support is the right place where to demand...
I honor OpenSource very much and I strongly disagree, that one (maybe import module) community should do the work and the others (PO) should collect $$.
As far as I understand, the problem is NOT SQLite, but the form of data (wrong path) which are stored there - the responsible for them is application (C1P, thus developer from PO).
Feel free to correct me if I am mistaken.0 -
It's a free utility with a specific purpose (and probably a short life) to help Aperture users migrate from a product Apply decided not to support - leaving their valued customers to look for alternatives it seems.
We have all paid for it, one way or another, but I am not a Mac or Aperture user so should I get a refund of some sort? The code is of no use to me at all and, presumably, took resources away from work from which I (and all other non-Aperture users) might have benefited.
Sure, placing a request for an enhancement through Support is fine and it would then be up to Phase to decide if the effort was useful enough to enough people to make sense as a development project. Feeling that you can make a demand related to a free add-on utility is a different matter. Had you paid for it you might have a more reasonable case ... perhaps Apple could offer you some financial help as compensation for the wasted years of effort you have had with Aperture? They could surely afford it.
I think you have a rather odd view of what Phase One have set out to offer people and what follow-on responsibility they may or may not have being driven by a group of users with very specific interests not necessarily required by other customers.
Grant0 -
[quote="SFA" wrote:
It's a free utility with a specific purpose (and probably a short life) to help Aperture users migrate from a product Apply decided not to support - leaving their valued customers to look for alternatives it seems.
...
Grant
Grant - still don't understand your point. What is free utility? C1P and File/Import Catalog/Aperture Library/ ??
if you think so, you're then wrong. In case customer paid for C1P, thus paid for background color, help, everything inside. I didn't pay YET - but you can be sure, once I finish my choice and realize, that I'll pay - I won't be satisfied with buggy SW. In case I use that built-in function - then I expect no mismatch of my data. No matter who is developer behind - is community or PO builder machine. I bought from PO, thus expect support from them - unless stated in terms otherwise.
So still don't understand the point why I should claim anything from Apple. They did they work, decided not to continue - their choice. They offered me support for certain time.
Why this should be wrong to claim support from PO when I bought SW? (imaginary - I still didn't yet).0 -
[quote="PaaS" wrote:
[quote="SFA" wrote:
So still don't understand the point why I should claim anything from Apple. They did they work, decided not to continue - their choice. They offered me support for certain time.
So they took your money for some years, got you committed to the Aperture way as the only way and then dropped you when they decided to take a different route that you do not like. No compensation from them for all of the time you spent adopting to their concepts only to have them abandon you.
Now you look for Aperture from a different vendor but don't find an exact match.
So you expect any potential new vendor to change what they do to be more like Aperture just because you want it to be that way. And if their design is currently different you call that a bug and suggest that they must change what they do or you will claim that the software is "buggy".
So, the new vendor may or may not choose to adopt the Aperture design that you want them to adopt - "their choice" as you said about Apple and the Aperture decision. So why not just accept it for what it is, as you seem to have done in the case of Apple, and simply ask if a change to be implemented rather than make remarks about "bugs"?
Grant0 -
[quote="SFA" wrote:
[quote="PaaS" wrote:
[quote="SFA" wrote:
So still don't understand the point why I should claim anything from Apple. They did they work, decided not to continue - their choice. They offered me support for certain time.
So they took your money for some years, got you committed to the Aperture way as the only way and then dropped you when they decided to take a different route that you do not like. No compensation from them for all of the time you spent adopting to their concepts only to have them abandon you.
Now you look for Aperture from a different vendor but don't find an exact match.
So you expect any potential new vendor to change what they do to be more like Aperture just because you want it to be that way. And if their design is currently different you call that a bug and suggest that they must change what they do or you will claim that the software is "buggy".
So, the new vendor may or may not choose to adopt the Aperture design that you want them to adopt - "their choice" as you said about Apple and the Aperture decision. So why not just accept it for what it is, as you seem to have done in the case of Apple, and simply ask if a change to be implemented rather than make remarks about "bugs"?
Grant
Again! What are you thinking about is wrong - you put it wrongly in different meaning. This NOT about Aperture nor Apple. It's NOT about 'design' - it's about mismatching data. If you can see duplicities in tree structure. If SW pretends to import something and you actually see it somewhere else - it's BUG. You can call it 'different design' I am calling it BUG, because - it IS bug. Even the reporter ^^ (read few comments back) was able to FIX it - FIX means to change something from bad to good behaviour. You can call it maybe 'to polish design'.
And again - NO, OpenSource nor Apple is not designer/developer of broken C1P 😉 So please don't blame wrong group.
You maybe don't care as you are not the one who has some work(pleasure in my case) somewhere where you want to migrate to somewhere else. I can export, prepare sidecars, change exifs/iptc - but why to do some additional work? I've few Libraries and there are bunch SW which can deal wit import - as C1P claims they can - why shouldn't I complain when they're doing it wrongly? (yes, it's a bug) 😊
No matter if I used to use Aperture,Gimp,Paintshop or <name-it> - if C1P offers functionality & it returns data incorrectly - you shouldn't call that DESIGN..
P.0 -
[quote="rjackb" wrote:
I have successfully imported about 11,000 referenced images from my Aperture library into Capture One 8.2.1. After the import, my Aperture projects show up as Capture One collections and my folders show up in a folder tree. The problem is that when I import a brand new set of images into a new folder, the folder shows up in a separate tree that looks identical except for a few icons. I really don't want to have to separate folder tree but rather add on to my existing tree. I'll try indicate what I am seeing below? Thank you.
v <icon> Macintosh HD
v <icon> Users
v <icon> Jack
v <icon>Desktop
v <icon> Images
v <icon>Nikon D300
<icon>2015-04-18 <- new folder added but want in tree below
v <icon> Macintosh HD
v <icon> Users
v <icon> Jack
v <icon>Desktop
v <icon> Images
v <icon>Nikon D300
<icon>2005-01-01 <- folder that I imported
<icon>2005-01-02 <- folder that I imported
... many more folders imported from Aperture ...
The problem is your Aperture import. CO8 - for some reason - stores the directory tree of an Aperture import differently that it would normally do. I had the same problem. If you are fine with running php scripts from a console window, let me know and I post the program.0 -
Hi, [quote="mercator" wrote:
CO8 - for some reason - stores the directory tree of an Aperture import differently that it would normally do. I had the same problem. If you are fine with running php scripts from a console window, let me know and I post the program.
Would it be possible for you to explain a bit more about this? I'm not a programmer but the duplicate folder structure is annoying me too.
I have built a new catalog from scratch due to problems with adjustments not recognized by C1 when importing from Aperture. I had to export smaller parts of my library fom Aperture as separate new libraries and to import these one by one into C1. Now all adjustments are fine and I have a single folder tree. But I assume as soon as I import new images into C1 the duplicate folder structure will be back.
Could your script help with this and can it be used by an old dummy like me with no programming- php- sqlite- skills at all?
Thanks in advance and best regards,
Frank0 -
Hi,
just a follow up on the duplicate folder tree issue.
I have done some research myself and then edited the C1Pro catalog database and now my folder section in the library tool displays a single folder tree that includes all folders containing images regardless where they originate from (Aperture or directly imported into C1).
It seems the duplicate folder tree is not PhaseOne’s fault. When I upgraded my brother’s iMac with more RAM and SSD his referenced Aperture Library was broken (all images were displayed as offline) because we had changed the name of the hard drive to Macintosh SSD. It was easily fixed but it seems to prove that Aperture assigns absolute pathnames (/volumes/Macintosh HD/users/username/pictures/...) to referenced images. The Aperture-Importer of C1 copies these on import while images directly imported have relative pathnames (users/username/pictures/....).
I have no idea about SQLite databases and I will keep my old catalog for quite a while just in case I screwed anything up that I just haven’t noticed yet.
Also be warned: it is laborious and time consuming (took me two hours and my catalog contains just little more than 5000 pics) and a single typo can ruin it all so if anyone wants to do it be very careful.
After reading several sites about SQLite database editing I first downloaded and installed sqlitebrowser, a tool to browse and edit SQLite databases.
Launch it and open the *.cocatalogdb inside your C1-catalog package (be sure to make a copy of it and put it in a safe place before that). The window has two parts and the right one can be closed since it is not used here. The other part displays the database structure by default. Change it to „search data“ (or something similar, my OSX is in German) and select the table „ZPATHLOCATION“ from the drop down menu.
Once the table is displayed change the width of the rows by dragging the dividers in the title line so the content is perfectly readable.
You can easily identify the rows that need to be edited. Thes are named „ZMACROOT“, „ZRELATIVEPATH“ AND „ZVOLUME“.
In ZMACROOT every entry that reads „/volumes“ must be changed to read „/“.
In ZRELATIVEPATH every entry that starts with „/Macintosh HD/Users...“ must have „/Macintosh HD/“ removed (14 characters) so it starts with „Users/...“ or is empty.
In ZVOLUME every entry that reads „NULL“ must be edited to read „Macintosh HD“.
That’s it. Click on „write changes“ in the toolbar, close the progam and open the edited catalog in C1. Everything should be unchanged exept for the folder section of the library tool. It now displays a single folder tree and all your folders and images are still there.
Good luck...
Frank0 -
I would advise you manipulate the database only RIGHT AFTER the Aperture import. The PHP script below does it for you:
<?php
/*
PATHCHANGER: Adapt paths in a Capture One Pro database RIGHT after importing an Aperture Catalog
CALL: php pathchanger.php <Capture On Pro database file>
EXAMPLE: php pathchanger.php CaptureOne/CaptureOne.cocatalogdb
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
Copyright (C) 2015 by Helmut Kaufmann
*/
class MyDB extends SQLite3 {
function __construct()
{
global $argv;
$this->open($argv[1]);
}
}
$db = new MyDB();
if(!$db)
echo $db->lastErrorMsg();
$sql="SELECT ZMACROOT,ZRELATIVEPATH FROM ZPATHLOCATION WHERE ZRELATIVEPATH LIKE '_Macintosh HD%'";
$ret=$db->query($sql);
while ($row = $ret->fetchArray(SQLITE3_ASSOC)) {
echo $row['ZMACROOT'] . "/". $row['ZRELATIVEPATH']."\n";
$oldPath=$db->escapeString($row['ZRELATIVEPATH']);
$newPath=$db->escapeString(substr($row['ZRELATIVEPATH'], 14, 999));
$foo=$db->exec("UPDATE ZPATHLOCATION SET ZMACROOT = '/' WHERE ZRELATIVEPATH='$oldPath'");
if(!$foo){
echo $db->lastErrorMsg();
} else {
echo $db->changes(), " Record updated successfully\n";
}
$foo=$db->exec("UPDATE ZPATHLOCATION SET ZVOLUME = 'Macintosh HD' WHERE ZRELATIVEPATH='$oldPath'");
if(!$foo){
echo $db->lastErrorMsg();
} else {
echo $db->changes(), " Record updated successfully\n";
}
$foo=$db->exec("UPDATE ZPATHLOCATION SET ZRELATIVEPATH = '$newPath' WHERE ZRELATIVEPATH='$oldPath'");
if(!$foo){
echo $db->lastErrorMsg();
} else {
echo $db->changes(), " Record updated successfully\n";
}
}
$ret->finalize();
$db->close();
?>
You need to call it as follows, assuming that the user name is USER, the database is DB and the script above has been saved as pathchanger.php:
pathchanger.php /Users/USER/Pictures/DB/DB.cocatalogdb
You might want to back up the database (the .cocatalogdb file) before you call the script.0 -
mercator,
thank you for your reply and also for the code.
But if you read my post above yours you might see that my problem is already solved.
My solution is not as elegant as your script of course but it worked out fine.
It helped me a lot to do it when I also had already imported images with CaptureOne itself. This way the difference between the datasets form this import and from the Aperture import could clearly be seen in the ZPATHLOCATION-table and I knew imediately wich fields to edit.
The rest was just a bit of work.
Best regards,
Frank0 -
Hi Frank,
Read your post and thought someone might have the same problem. As I already had the code, I just posted it.
Enjoy May 1,
Mercator0
Post is closed for comments.
Comments
21 comments