Ah, interesting. I'm using Windows 7 with the built in extractor in Windows Explorer. I'll try again with 7zip and report back.
EDIT: I tried with 7zip and everything works perfectly. My theory is that the CON folder which couldn't be extracted by Windows may have created issues with all cards stored after it in the zip archive. Sorry for the false alarm.
Aye, it's the CON folder.
See the 'Windows Warning' message I have about this in the 'zip' section on: http://mtgimage.com/
I extracted it and the directories you mentioned have images, the images are of non-zero size and they are viewable and look ok.
What operating system are you using and what program are you using to unzip the files? I will then use the same to see if I can reproduce the issue you are seeing.
So I just took a look at the zip file and I see the directories mentioned with images in them. Could you elaborate a bit more about what is broken about them? Are there images missing? If so, could you provide a couple examples?
Sembiance, did you see my post about the vintage-only cards in Commander 2014 and Conspiracy? I think it might have gotten lost in the posts about UUIDs.
Aye, I did see it. I haven't had a chance to investigate yet, currently traveling. I will look into it as soon as I am able.
Sembiance, I don't want to rush you with deciding about A, B or C, but if you at least could state which solution you're leaning to, that'd be nice. I've got an app waiting to be released and this UID thing is very important to me as on the Apple platform updates take a week to be reviewed and let into the App Store, so providing a reliable app is crucial.
I have decided to go with a variation of C.
I won't be changing any imageName fields for any existing cards or sets.
In the future whenever a new card is released, it's imageName field won't change in the future.
So everyone can rely on it for UID purposes.
For my reasoning, I decided not to change all existing imageNames because that would just hurt a ton of existing users that already use this data. Future regular sets that get released will continue to use the existing conventions. The only thing that will change convention wise in the future, is for the rare cases in promo sets where another card is added with the same name of another card already in the promo set. In these cases the imageName for the new card will have the number suffix but the existing imageName field for the old card will not change. I believe this is the best path for all users of the data.
Thanks for helping me weigh out the pros and cons.
Why would you change an already available imageName, when you could just add the "2" to the other and everything would be just fine? It would break your current image naming convention, true, but would certainly futureproof your database. What do you think?
I already have it so that "Card.jpg" still works. It behind the scenes points to "Card1.jpg"
So while the JSON imageName entry may change, both the old and new values still work.
As for changing it so that imageName just gets a number appended to the end and leave the original alone, that is indeed how I should have done it at the beginning. I didn't have promo image sets back then, so sets never changed after being released so it wasn't a concern back then. I guess I have 3 options:
A. Do nothing, continue as usual
B. Retroactively change all existing imageName fields and all imageName fields going forward
C. Only change upcoming imageName fields
I know it's not a simple 'version.json' file with just the version, but the first entry in the changelog.json file is always the most recent and it contains a 'version' field that you can check.
I forgot to document that this file exists and so I just updated the site to make note of it.
Hi Sembiance,
To the questions regarding the unique id:
I'm currently using setcode,name,number,multiverseid and this provides (so far) a unique robust way of identifying cards.
The only problem you may run into is not all cards have multiverseid's because they do not exist on Gatherer (most promo cards and some other sets).
Also a card doesn't always have a number field either. Older cards don't have them and I can't guarantee that all future promo cards will have them.
setCode+name isn't quite enough because you can have more than one card in the set with the same name.
It's a tricky problem because a promo set could have two cards that differ only in something very minor, like the 'source' or 'releaseDate' or some other trivial field. At this time I don't have a strong recommendation as to how to have a unique id that is guaranteed to be unique into the future.
All that being said, I'd say go with whatever works right now (which it sounds like your current field combinations works right now) and then just have some sort of check in the future to ensure that newly released or changed sets don't have any duplicate id's.
So just a note, I was wrong in saying 'imageName' is safe to use for a key. It can change in 'promo' sets.
For example, I just did an update to pWPN set which includes another Fringe card. This means the original 'fringe' is now 'fringe1' and there is also now a 'fringe2'.
I thought I'd make people aware of this possibility in future updates.
hi sembiance, any plans on serving the images on a secure connection? i'd like to use ssl on my site, but i'm not sure how i would then use mtgimage, apart maybe from proxying. directly hotlinking as i do now would show a warning to the user about loading insecure content.
I do not currently have any plans to add https support to mtgimage.com
I know a few others have wanted this. Some ended up downloading the images to serve them locally. Another ended up proxying requests over to mtgimage through their server. I believe it's pretty simple in nginx to set up a proxy to go back to mtgimage.com, although I haven't look into this myself.
The hash is just a checksum. It takes the input data and outputs a 512/256/128 bit number. The multiverseid in the hash won't prevent overlap.
Of course it won't, but the chance to actually experience one should be somewhat smaller.
EDIT: Just to make sure... does *every* card in the DB have a card number? I mean, Sembiance has tokens in his todo list for the site. There also are Planechase/Archenemy cards. Could them mess the UID up?
Not all cards have a number field. Also not all cards have a multiverseid field. So neither can be relied upon for providing a UID. I believe basing it on setCode+cardName+imageName will provide a UID for a card. setCode+cardName gets you 99% of the way there, then imageName is different for cards that have the same name within a single set. So that gets you the rest.
I haven't double checked this UID against the data set, but it should be solid.
Aye, it's the CON folder.
See the 'Windows Warning' message I have about this in the 'zip' section on: http://mtgimage.com/
Basically as a Windows user you want to download the Windows compatible zip file: http://mtgimage.com/zip/AllSetsWindows.hq.zip
Glad to hear though that 7zip worked around it for you.
Fixed. I have updated legalities for all cards in all sets.
So I just double checked by downloading the file: http://mtgimage.com/zip/AllSets.hq.zip
I extracted it and the directories you mentioned have images, the images are of non-zero size and they are viewable and look ok.
What operating system are you using and what program are you using to unzip the files? I will then use the same to see if I can reproduce the issue you are seeing.
So I just took a look at the zip file and I see the directories mentioned with images in them. Could you elaborate a bit more about what is broken about them? Are there images missing? If so, could you provide a couple examples?
Thanks
Aye, I did see it. I haven't had a chance to investigate yet, currently traveling. I will look into it as soon as I am able.
I have decided to go with a variation of C.
I won't be changing any imageName fields for any existing cards or sets.
In the future whenever a new card is released, it's imageName field won't change in the future.
So everyone can rely on it for UID purposes.
For my reasoning, I decided not to change all existing imageNames because that would just hurt a ton of existing users that already use this data. Future regular sets that get released will continue to use the existing conventions. The only thing that will change convention wise in the future, is for the rare cases in promo sets where another card is added with the same name of another card already in the promo set. In these cases the imageName for the new card will have the number suffix but the existing imageName field for the old card will not change. I believe this is the best path for all users of the data.
Thanks for helping me weigh out the pros and cons.
I already have it so that "Card.jpg" still works. It behind the scenes points to "Card1.jpg"
So while the JSON imageName entry may change, both the old and new values still work.
As for changing it so that imageName just gets a number appended to the end and leave the original alone, that is indeed how I should have done it at the beginning. I didn't have promo image sets back then, so sets never changed after being released so it wasn't a concern back then. I guess I have 3 options:
A. Do nothing, continue as usual
B. Retroactively change all existing imageName fields and all imageName fields going forward
C. Only change upcoming imageName fields
This is available in: http://mtgimage.com/changelog.json
I know it's not a simple 'version.json' file with just the version, but the first entry in the changelog.json file is always the most recent and it contains a 'version' field that you can check.
I forgot to document that this file exists and so I just updated the site to make note of it.
The only problem you may run into is not all cards have multiverseid's because they do not exist on Gatherer (most promo cards and some other sets).
Also a card doesn't always have a number field either. Older cards don't have them and I can't guarantee that all future promo cards will have them.
setCode+name isn't quite enough because you can have more than one card in the set with the same name.
It's a tricky problem because a promo set could have two cards that differ only in something very minor, like the 'source' or 'releaseDate' or some other trivial field. At this time I don't have a strong recommendation as to how to have a unique id that is guaranteed to be unique into the future.
All that being said, I'd say go with whatever works right now (which it sounds like your current field combinations works right now) and then just have some sort of check in the future to ensure that newly released or changed sets don't have any duplicate id's.
For example, I just did an update to pWPN set which includes another Fringe card. This means the original 'fringe' is now 'fringe1' and there is also now a 'fringe2'.
I thought I'd make people aware of this possibility in future updates.
1: https://github.com/Sembiance/mtgjson
2: There is no list of all projects using mtgjson/mtgimage at this time.
3: The 'legalities' key has this information. If the key (format type) has the value 'Banned' then it is banned.
I do not currently have any plans to add https support to mtgimage.com
I know a few others have wanted this. Some ended up downloading the images to serve them locally. Another ended up proxying requests over to mtgimage through their server. I believe it's pretty simple in nginx to set up a proxy to go back to mtgimage.com, although I haven't look into this myself.
Sorry I don't have better news for you.
Not all cards have a number field. Also not all cards have a multiverseid field. So neither can be relied upon for providing a UID. I believe basing it on setCode+cardName+imageName will provide a UID for a card. setCode+cardName gets you 99% of the way there, then imageName is different for cards that have the same name within a single set. So that gets you the rest.
I haven't double checked this UID against the data set, but it should be solid.