Comparison between EE and others

[c_by_sinus]

Hi EE-users,
(Still) on the search for the best ;) Online-system, I have made a very small comparison.
Because I do not know EE very well, please could someone check this list out and mail me, if there are faults on the list?
This would be very nice.
When the list is finnished, I have then something to show for people, who asks me a lot for the BEST online-system.
EE is very compromising, and I hope, the upcoming version will rock.
Thanks, here is the link:

http://www.sinus.ch/onlinegalleries.html

Markus

[Pekka]

There is one thing which in my opinion should be mentioned: EE is currently (and does not try to be anything else than) a personal gallery solution (one updater admin at a time), contrary to others which are designed to be community gallery solutions. I have plans to make a "community EE" in version 1.7, after adding lightbox, E-cards and private authenticated press sale system in 1.6. But community gallery system has never been my main goal.

Is there a logging-system for the searched keywords: yes

and in release version on 1.5:

Is there also a logging-system for the admin: yes

Might be nice to mention also:
cross-server image retrieval: yes (any big size photo can be on any server = server load/bandwidth distribution)

[Pekka]

BTW: I think we talked about this earlier, but now would be a good time to decisively decide about IPTC categories how they are added in EE. If you have

main category

CAT

supplemental categories
supplemental category 1
supplemental category 2
supplemental category 3
supplemental category 4


Should EE in case a supplemental category is not already found in system add it, and should it use main category name in the added name any way

supplemental category 1 (CAT)
CAT / supplemental category 1

or should it treat all equally?

This is actually some of the last things to code in 1.5, and I'm doing it this week so all comments are now very welcome.

[c_by_sinus]

Hi Pekka,
Thanks for the FAST answer.
I will change/add your proposals this evening.
Thanks for that.
Markus

[c_by_sinus]

Hi Pekka,
You are right, we have talked about this, but to be honest ... I thought, you will it forget, because you must have such a huge list for to do ;)
But I am of course VERY happy to hear, that your are not only listening, but also not forgetting ;)
OK, I can of course only speak for me.
The best thing would be -as usual- that we could choose the followings:

-Should EE add new supplemental categories, if not already there in EE
-Should EE add the main category or not

If this is to complicated, for me it would be clear:
-EE should take ALL supplemental categories into EE categories
-if one or more Categories are not in EE, then EE should create these
-EE should NOT take the main category (CAT) into EE

Let us say, I have an image with this:
main category
SPO

supplemental categories
Nature
Animals
Jungle


Then EE should NOT take SPO into the categories, only in a "normal" field (like other iptc-fields, also for searching). Because this main category allows only 3 characters, usually to add this as categories makes no sense for users, who wants look at the images (but should be possible for searching)

But EE should take this image into the three categories Nature, Animals and Jungle.
And if one or more from this three categories would not exists, EE should create them.

This would be great for me.
BUT anyway, if you even decides to do this in another way (like add main cat too) this is OK for me.
The main task and great would be, that EE would look into the iptc-supplemenal-Categories from an image, and if EE finds some, it would throw this image into all EE-cats too.

Compared for example with 4images (version now) this would be a realy big, big advantages for all, who working with iptc.
Because all iptc-infos we have already in an image, so we have not the same work twice (like adding categories).
And these people, who does not work with iptc, these images would simply not involved into this "scheme".

If you will realize this, then EE would be possible to use the iptc for uploading (take the infos and work even with the cats-infos) and use this iptc-infos for searching (mostly keywords) and for the categorie in EE.
Simply great!
Thanks a lot, Pekka.

Markus



BTW: I think we talked about this earlier, but now would be a good time to decisively decide about IPTC categories how they are added in EE. If you have

main category

CAT

supplemental categories
supplemental category 1
supplemental category 2
supplemental category 3
supplemental category 4


Should EE in case a supplemental category is not already found in system add it, and should it use main category name in the added name any way

supplemental category 1 (CAT)
CAT / supplemental category 1

or should it treat all equally?

This is actually some of the last things to code in 1.5, and I'm doing it this week so all comments are now very welcome.

[c_by_sinus]

Hi Pekka,
Thanks for the FAST answer.
I will change/add your proposals this evening.
Thanks for that.
Markus

Done, list is now online again:
http://www.sinus.ch/onlinegalleries.html

Markus

[dboschung]

Hi together

I only can support what Markus said about categories and would realy appreciate that feature. This way the whole work of keywording and categorising in other programs would not be lost.

Daniel

[Mangowarrior]

Hi All,

Thanks to Markus for laying out an excellent suggestion for category import. For those of us that use Imatch or similar and have done a lot of work with entering IPTC info, it would be great to have EE do as Markus has suggested.
Looking forward to it Pekka! :D

[Pekka]

Current situation in developement version, the selections add only if the category (formatted by selection) is not already there in EE.

http://photography-on-the.net/ee/beta/upload.gif

http://photography-on-the.net/ee/beta/moduletest.gif

IPTC data is read by both internal XMP/XMA reader and IPTC function, so if IPTC function is not available for some reason IPTC will be read from PS files nevertheless.

[TomKa]

Some thoughts about a commercial gallery version:

EE is very good for personal galleries, and including the IPTC code into the database is big step ahead to feed a great amount of pictures into the gallery.

Looking around for a commercial version of a gallery to sell pictures online I haven't found very much excluding ImageFolio Commerce. All other solutions are too expensive to start such a business as a secondary employment to sell pictures over the net.

Searching from the other side, beginning with open source E-shops, I have found osCommerce (http://www.osCommerce.com) (example www.fotopack.com ) and a running project at work (http://www.coconutcity.com/shop/) which uses IPTC code from the pictures to feed the shop database.

Maybe this could be a better solution for shop, if the tasks for shop and gallery are divided. Perhaps it's possible to use the data from the Exhibit Engine to feed the database of the shop, so it's possible to use the same pictures for the shop and also for gallery. Somebody who wants to buy pictures in a professional manner goes for shop, if you want to see the pictures without the commercial stuff you go for the gallery (with the EE commerce solution), and the pictures and thumbnails are shared between the shop and the gallery.

What are you thinking about such a solution?

[c_by_sinus]

Hi Pekka,
this looks great!
To be sure, that I understand it right:

I have an image with the following IPTC-fields:
Cat:
FRE
Suppl. Categories:
Animals
Fashion
Music
People
Art

In EE, I would have only the following Categories:
Animals
Fashion
People

Now, with the right choice I would get this:
This image would be added to the EE-categories
Animals
Fashion
People

The two others would be genereated automatically, and then in these two new categories would be at the moment only this new image. The new created categories in EE would be:
Music
Art

Is this correct? And now, what would happen with the iptc-field Cat, in this example with the iptc-category
FRE?
Would this threaded like a normal Suppl. Category or ignored? When I look at your dropdown-list, I guess, I could choose for example "Add subcategories only" and the Cat "FRE" would be ignored. Is this correct?

For me it looks, as you gives the user ALL possible choices and this is simply cool and very "timesaving".
Thanks Pekka, that you look at this whole stuff so seriously. As you can see in other programs like yours, the iptc-stuff is often not implemented or only "a bit". Hence EE will be a very interesting alternative for all users, who works with iptc.
Markus









Current situation in developement version, the selections add only if the category (formatted by selection) is not already there in EE.

IPTC data is read by both internal XMP/XMA reader and IPTC function, so if IPTC function is not available for some reason IPTC will be read from PS files nevertheless.

[Pekka]

Hi Pekka,
this looks great!
To be sure, that I understand it right:

I have an image with the following IPTC-fields:
Cat:
FRE
Suppl. Categories:
Animals
Fashion
Music
People
Art

In EE, I would have only the following Categories:
Animals
Fashion
People

Now, with the right choice I would get this:
This image would be added to the EE-categories
Animals
Fashion
People

The two others would be genereated automatically, and then in these two new categories would be at the moment only this new image. The new created categories in EE would be:
Music
Art

Is this correct? And now, what would happen with the iptc-field Cat, in this example with the iptc-category
FRE?
Would this threaded like a normal Suppl. Category or ignored? When I look at your dropdown-list, I guess, I could choose for example "Add subcategories only" and the Cat "FRE" would be ignored. Is this correct?


It works exactly as you describe.

I have not yet decided if there is a need to have first letter capitalization on sub-categories but as editing of category names is easy after upload I'm not sure if it is needed.

All comparisons (existing to IPTC) are done case-insensitively).

Comparing to database is done with the selected format: example:

Main category
DOG
subcategory is
bones

You choose format
CAT | subcategory

the comparison to database is done with

DOG | bones

and it will consider

bones (DOG)

or

bones

a different category. This is why one should stick to certain format. Or edit them later to match.

There is also a question about those "odd" IPTC fields:

urgency
special instructions
credit byline
credit byline title
transref
photo_source
caption_writer

Do these need to be inserted in db? I can do it, but where would they be used in display?

Now I use either copyright or credit as photographer. Perhaps these should be separated?

[Pekka]

Some thoughts about a commercial gallery version:

EE is very good for personal galleries, and including the IPTC code into the database is big step ahead to feed a great amount of pictures into the gallery.

Looking around for a commercial version of a gallery to sell pictures online I haven't found very much excluding ImageFolio Commerce. All other solutions are too expensive to start such a business as a secondary employment to sell pictures over the net.

Searching from the other side, beginning with open source E-shops, I have found osCommerce (http://www.osCommerce.com) (example www.fotopack.com) and a running project at work (http://www.coconutcity.com/shop/) which uses IPTC code from the pictures to feed the shop database.

Maybe this could be a better solution for shop, if the tasks for shop and gallery are divided. Perhaps it's possible to use the data from the Exhibit Engine to feed the database of the shop, so it's possible to use the same pictures for the shop and also for gallery. Somebody who wants to buy pictures in a professional manner goes for shop, if you want to see the pictures without the commercial stuff you go for the gallery (with the EE commerce solution), and the pictures and thumbnails are shared between the shop and the gallery.

What are you thinking about such a solution?

Yes I am thinking of supporting some mass sale system on the side. Big problem with all GPL software is that using their code even a bit is not an option (EE would have to be GPL too) and they are usually extremely messily coded (dozens of mods and code styles). I'll try to contact them nevertheless to see if there if sharing data is possible.

[c_by_sinus]

It works exactly as you describe.

I have not yet decided if there is a need to have first letter capitalization on sub-categories but as editing of category names is easy after upload I'm not sure if it is needed.
All comparisons (existing to IPTC) are done case-insensitively).
Comparing to database is done with the selected format: example:

Main category
DOG
subcategory is
bones

You choose format
CAT | subcategory

the comparison to database is done with

DOG | bones

and it will consider

bones (DOG)
or
bones

a different category. This is why one should stick to certain format. Or edit them later to match.

There is also a question about those "odd" IPTC fields:

urgency
special instructions
credit byline
credit byline title
transref
photo_source
caption_writer

Do these need to be inserted in db? I can do it, but where would they be used in display?

Now I use either copyright or credit as photographer. Perhaps these should be separated?

Hi Pekka,
thanks for the anwers. So far as I can see, the category/supplemental category-stuff is clear for you.

About the odd iptc -fields:
From my point of view:
Yes, credit and copyright should be separated, because in agencies these are sometimes two separate things (though mostly not).
BTW: the name of the photographer is mostly used in the field "By-line" (ID 80), credit is used for who is the salary and copyright is sometimes again someone else. But you are right, sometimes the photographer can be also the man for the salary and the copyright-holder ;)
But in the area of agencies this varies sometimes (like for example "Keystone/Warren Sannikka" where Keystone is in the credit-field, Sannikka in the By-line field as photographer and maybe Getty-images holds the copyright (as an example only, not actually true).

Because you said it right, these fields (and some others) are odd, because they are not widely in use, and if, sometimes they have different meanings.
The best thing of course would be, the system takes ALL fields into the database from EE. And then, to display under an image, we could choose each field to display.

For me/us for example,

the most important fields are:
Supplemental Category (ID 20)
Keywords (25)
Date Created (55)
By-line (80)
City (90)
Provinz/State (95)
Country Primary Location Name (101)
Headline (105)
Caption/Abstract (120)


Medium important are:
Object Name (5)
Category (15)
Fixture Identifier (22)
Special Instructions (40)
Time Created (60)
Originating program (65)
By-line Title (85)
Country Primary Location Code (100)
Original Transmission Reference (103)
Credit (110)
Source (115)
Copyright Notice (116)


Not important are:
Edit Status (7)
Urgency (10)
Release Date (30)
Release Time (35)
Object Cycle (75)
Sublocation (92)
Writer/Editor (122)


Now, if I had only the most important fields from my list above, and then, when I could choose the fields from these to display under each image, wow, I would be more than happy!!
Oh, and not to forget, we should also be able to search for this, of course, but I have seen, this is not a problem for EE.

But of course, maybe another must have the field "By-line Title" (ID85) as an example, and then he would be very unhappy, if he could not display this under each image.
Maybe other users could also write, what they wish. But generally, you know this better than me, if you decides, field x and y are not important, I take this not into EE, than for sure users ask some days later for exactly these two fields ;)

Generally, most used fields, also for displaying, are Caption, Headline, Keywords, date and of course (out of iptc) the filename.

Sorry for writing again so much and in so bad English, Pekka.
Best wishes
Markus

[c_by_sinus]

Hi Pekka and others,
For the iptc-stuff, I made a table and put this online.
Maybe there are some hints for you, I do not know.
I guess, I will get some more infos about the use of iptc, because I uploaded the table also in some other forums, for example IMatch.
I created it because your remarks about "odd iptc-fields", what is quite a correct impression from you. Some fields are "odd" also, because they are mostly not in use or these fields have very different meanings for iptc-users.

After collecting some infos, I will update the table of course and let you know this.
But generally, the table should now represents quite a wide area of iptc-users.
Thanks and here is the link:

http://www.sinus.ch/iptctable.html

Markus

[Pekka]

Thanks Markus, that is very informative.

I have added to EE something to control display of photo detail under photo (or wherever template puts it) in extreme fashion: now you can choose what items will be displayed, in what order the are displayed, and is division character or linefeed used between (each separately) . All this can be set up in one easy editor which is part of misc settings. I'll post more about that tomorrow.

[c_by_sinus]

Thanks Markus, that is very informative.

I have added to EE something to control display of photo detail under photo (or wherever template puts it) in extreme fashion: now you can choose what items will be displayed, in what order the are displayed, and is division character or linefeed used between (each separately) . All this can be set up in one easy editor which is part of misc settings. I'll post more about that tomorrow.

Hi Pekka,
THANKS for this. This sounds like xmas ;)
Markus

[Evanrich]

Hi EE-users,
(Still) on the search for the best ;) Online-system, I have made a very small comparison.
Because I do not know EE very well, please could someone check this list out and mail me, if there are faults on the list?
This would be very nice.
When the list is finnished, I have then something to show for people, who asks me a lot for the BEST online-system.
EE is very compromising, and I hope, the upcoming version will rock.
Thanks, here is the link:

http://www.sinus.ch/onlinegalleries.html

Markus

Uh dude.. you put the comment from pekka under the 4 images catagory way at the bottom, better go stick it under the right program.

[TomKa]

...Europe is goin' nuts, especially the precision of Switzerland. Markus, Markus.... :cry:

[c_by_sinus]

Hi EE-users,
(Still) on the search for the best ;) Online-system, I have made a very small comparison.
Because I do not know EE very well, please could someone check this list out and mail me, if there are faults on the list?
This would be very nice.
When the list is finnished, I have then something to show for people, who asks me a lot for the BEST online-system.
EE is very compromising, and I hope, the upcoming version will rock.
Thanks, here is the link:

http://www.sinus.ch/onlinegalleries.html

Markus

Uh dude.. you put the comment from pekka under the 4 images catagory way at the bottom, better go stick it under the right program.

Hi,
Shame on me, thanks for that, I will update the list in 15 minutes... but you see, I work on the table ...
Markus

[c_by_sinus]

...Europe is goin' nuts, especially the precision of Switzerland. Markus, Markus.... :cry:

OK, Thomas,
you got me. :oops:
I will try even harder to be more precisily ;)

Markus

[c_by_sinus]

Some thoughts about a commercial gallery version:

EE is very good for personal galleries, and including the IPTC code into the database is big step ahead to feed a great amount of pictures into the gallery.
Looking around for a commercial version of a gallery to sell pictures online I haven't found very much excluding ImageFolio Commerce. All other solutions are too expensive to start such a business as a secondary employment to sell pictures over the net.

Searching from the other side, beginning with open source E-shops, I have found osCommerce (http://www.osCommerce.com) (example www.fotopack.com ) and a running project at work (http://www.coconutcity.com/shop/) which uses IPTC code from the pictures to feed the shop database.
Maybe this could be a better solution for shop, if the tasks for shop and gallery are divided. Perhaps it's possible to use the data from the Exhibit Engine to feed the database of the shop, so it's possible to use the same pictures for the shop and also for gallery. Somebody who wants to buy pictures in a professional manner goes for shop, if you want to see the pictures without the commercial stuff you go for the gallery (with the EE commerce solution), and the pictures and thumbnails are shared between the shop and the gallery.
What are you thinking about such a solution?

Hi Tom,
hmm, this business drives me mad :roll:
First I must say, I do not fully understand the whole stuff in this area. I went to oscommerce, and this seems to look good, but when I go into the Forums, there are also a lot of problems, bugs, mods and so on. And also a lot of things, what from MY POINT OF VIEW, is not relevant for our business with photographs.
But bear in mind, as I said, maybe I see this stuff not in the right way or too easy.
Let us say, EE is one of the best galleries for photos out there. To be complete, it should only be there included a commerce-modul, what is now included, but not finnished (Pekka, I hope, I can say this :wink:

OK, the user found his wished image/s. Now we have some cases:

1) The photographer, who want only show his geat images: voila, done

2) The other, who wants let other user download his pics, even in different sizes: voila, done

3) The artist, who wants let other users download his pics, but want know, who has downloaded what image/s and what resolution (maybe the pics are on several servers in several resolutions): well, we must have a kind of modul "registration/password/logging" like there are a lot in use. We must first give our adress and email, then we get after a couple of minutes the passwords for enter. I believe, this is actuall not in ee, but should be not THAT difficult?

4) The optimist, who wants let other users download his pics, but want to know, who has downloaded what image/s for sending later an invoice: well, the same as the artist: the "registration/password/logging" - modul.

5) The business man, who wants let other users download his pics, but if the user wants download big sizes or the original, he must pay. Therefore the user must choose, what image/s in what size, maybe every size does cost different prizes: OK, here, we must have a sort of "shopping basket". The user puts his image/s into the basket, maybe even the same image in different sizes, collect maybe several images, and then he come to a "calculation-page" where he can see, what image/s he has choosen and how much costs all toghether. Of course he must be able to eliminate a choosen image still.
Then, when the prize is OK, he must go to a "cash-modul" and here he can choose between for example
PayPal
other credit-card- possibility
Invoice (for the optimist)

After this is finnished he will becomes the links for downloading the choosen images or he can have even the choosen images in a zip.

6) The manager, who wants all: he offers all like the business man, but also some printed images, some pics in frames and so on: Well, basically he needs all the same like the business man, a "shopping basket", a "calculation page" and the "cash-modul". He has only here and there more choices for the user, like for example in the "cash-modul" a point:
Nachnahme (sorry do not know the english word, means the user must pay immediatly when the delivery comes (for printed images).

So over all, we need four "moduls":

a) registration/password/logging-modul
b) shopping basket
c) calculation-page
d) cash-modul

Maybe I have forgotten a needed "modul" or two of my moduls are in fact only 1 modul.
But basically, would this not be enough? And would this be so difficult? As you said, Tom, in another thread, maybe a lot of users would be interested in this.
I would be ready also extra for paying such a super "commerce-system", because I guess, for some users, this is not necessary, for other users, this would be simply great.
But as you pointed out, there are not sooooooo many systems out there, maybe one system has such a commerce-system, but lacks in the gallery - part, others are old-fashioned programmed or again others are simply really to expensive.

Pekkas gallery part is super-cool, at the moment he lacks "only" for such a commerce-modul.

HOW Pekka could realize such a commerce-system, I do not know, and fairly, for me it does not matter, if Pekka does this by his own or with help/collaboration from other sides (like oscommerce). The most important is the good result, and here I guess, Pekka will choose the right way, because EE is "his child" and wants not the best for his children? :wink: (hey, Tom, I have also a 6year old daughter)

OK, sorry for again a long mail, sorry for my bad English and the third sorry for maybe understimate this whole stuff, but as I have said at the beginning, this drives me mad, when I think, how easy it could be ... and how difficult ...
Markus

[Pekka]

I'll just give some short comments (I'd love to write a novel about this but it's late here and I have concert day tomorrow).

a) registration/password/logging-modul

Easy, practically done already. What needs decisions is how permission system would manage what commerce pages people will see: you could e.g. rank people to "order prints", "order anything", "download size x", "download all sizes and bill" ranks or limit their orders to certain photos only.

b) shopping basket

Adding photos to lightbox/favourites/collection and managing it is technically easy.

c) calculation-page

Calculating various data from contents of aforementioned basket is easy. What can make it complicated is editor for prices and all sorts of options to set rules how framing and paper quality is related to print size and shipping method.

d) cash-modul

This is the most complex part. Well, not actually complex but in need of research. If you handle billing via mail or any commercial system like Paypal which uses data input systems they document properly then EE commerce can be used.

So the main task is to find those payment services you'd like to start using and then dig into its details and find ways to intergrate the EE commerce system data and lightbox to it. I'll be perfectly willing to work with you and anyone else who is willing to spend time talking about this and do some testing - I'm also going to sell prints with EE in future so this is something I will get done rather sooner than later.

What I have read in oscommerce site gets me this feeling: it seems to be an overkill to this problem and the code is so mixed it is very hard to integrate anything to it.

[TomKa]

d) cash-modul
This is the most complex part. Well, not actually complex but in need of research. If you handle billing via mail or any commercial system like Paypal which uses data input systems they document properly then EE commerce can be used.

Yes, the cash-module is the biggest problem. Doing B2B to agencies or editors a user system with download admission and counted downloads will be ok, because at the end of the month I will send the invoice to this regular customers.

Download points
Another proposal was something with points or a bonus for the download. The gallery owner sells 100 download points for a specific user. The points remain in the sql database for this user, with every (good) download some points will be charged from his account.

Paypal
Also Paypal (owned by Ebay) is getting more and more available in other language versions here in Europe.

EE-Interface for cash-modules
UPS and FedEx have little programs or code to integrate in a website for the tracking of shipped good. Now I don't know if there is a standard. Providing EE with a kind of Interface to plug in various modules for different solutions, anybody can ask a programmer or write (if he is able to) by himself a payment module to integrate in EE.

Just some thoughts to put a couple of ideas together.

[c_by_sinus]

I'll just give some short comments (I'd love to write a novel about this but it's late here and I have concert day tomorrow).Hi Pekka,
Good for the concert (hope it was successful), bad for you novel, what I would have read interestingly ... ;)


So the main task is to find those payment services you'd like to start using and then dig into its details and find ways to intergrate the EE commerce system data and lightbox to it. I'll be perfectly willing to work with you and anyone else who is willing to spend time talking about this and do some testing - I'm also going to sell prints with EE in future so this is something I will get done rather sooner than later. Of course I am interested too, therefore I would happy, when I could help you in some way (unfortunately not coding)


What I have read in oscommerce site gets me this feeling: it seems to be an overkill to this problem and the code is so mixed it is very hard to integrate anything to it.
To be realy honest, I had exactly the same feeling.
I see the point, that it is necessary to add some cash-services like Paypal.
But I do not know, how is the behaviour from the clients, who want buy images, in your country or in German, Austria, Italy and so on.
Here in Switzerland, it is very hard to bring the client to that point, that he makes some payment over the net with creditcard and so on.
A lot of people does not trust such services. So here it is very common, that we order online something, but receive the things by post AND with a normal, oldfashioned invoice on paper.
Even Nestle, the food-company, does some orders over the net here in Switzerland only in this way, you can order Nespresso and receive the fine coffee-capsules with a bill on paper.
And also a lot of other photographers, what I know, does work only in this way (often enough it is even not necessary to send an invoice, because a lot of medias like newspapers does pay when they print an image).

Therefore, and I can speak here of course only for me, a good starting point for me would be to do all the stuff what I described:

a) registration/password/logging-modul
b) shopping basket
c) calculation-page
d) cash-modul

and do the hardest thing, the cash-modul, in a first step, make only working on such a basis.
The user must then go through all the steps, but at the end he would have the possibility to click on "yes, send me an invoice" and after this, he could download the images or he would receive the images with the post and with an invoice.
For me personally this would be just wunderfull and more than enough.
And as far as I know for a lot of photographers, who work with newspapers, magazins and so, this is exactly what they must have, NOT MORE. They gives journalists, image-researcher and so on, the possibility, to download hi-res-images, and the only thing, what these clients must do, is go through the registration once, and then use the password.
And the EE-admin does know, who has downloaded what.
And if the newspaper does print the image, he can send an invoice or contact them or MOSTLY, as I said, the newspapers does contact the photographer or simpy pay the amount, what is usual for this specific newspaper.
On this way, you would give a lot of users one good possibility to use EE, because they need not more.

When I understand you right, then the rest is the hard thing, to include a real pay-service.
Therefore you could then (or parallel) look into this hard - stuff to give also the users, who must have a real cash-service, this possibility. But then you could add this functionality -I guess- to that, what you have done.
And if this takes more time than you thought, it is not that bad, because a part from users must simply not have this, and are happy with the "invoice-possibility".

Do not understand me wrong, I like also the full cash-service-possibility, but I do not use it now, maybe in 1 or 2 years, because, as I pointed out, even if I would offer it, a very big part of my users would just ignore this, they want now an invoice, basta.
With the expanding from Paypal also in Europe, this will change in the future, but this will take time.
Hence why not make this in two steps? I know, Pekka, you must code all, I do only throw into some thoughts of me.
Thanks for listening, at first I wanted write only 3 sentences, now there are again some more :oops:
Markus