About 1.24

[Pekka]

If anyone has any wishes for next version of EE please let me know. Now is the time to write if anything bothers you or you know bugs or flaws in 1.22. This is not a big update, EXIF, upload, translation, rating etc are all coming later.

In 1.24 beta I have now concentrated on small improvements and fixes here and there, and speed optimizing:

About speed improvement:

I have now made a dynamic speed optimizer for list.php for next version of EE. It works so that you first set a (into the list.php, or maybe in database) a "limit value". When you query photos, and when number of results is under the limit you set, the code uses RAM and PHP to sort and paginate the result. This will be 30-300% faster than when the result number is more than the limit value, and SQL will take care of sorting and pagination. With this limit value you can now define will your server use RAM for more speed, or will you use SQL server (conserver RAM, stress SQL). Usually e.g. 500 photos per result will sort faster with PHP, and over that the SQL will be faster because SQL handles very big results faster than PHP array sorting.

In short, you will have faster list.php :) If you put mouse over the EE logo in e.g. http://photography-on-the.net/gallery/list.php?exhibition=2 you will see how the page is optimised and how many seconds it took to do the main query and sorting. The limit is now 100 photos there.
This must be pretty academical to most of you, but this way you can direct EE to use the best technique possible to sort and paginate the results. Also, there has been interest to use EE in big photo sharing sites, where speed and RAM usage must be controlled.

Styles.php changed

I have changed styles.php so that entering new styles to the system is as comfortable as it can be.
Now, instead of entering several lines of code into different locations you only enter only one line for each style:

makestyle ("1", "styles/original.php", "Original");

Here you say that the style id is "1", the file for it is in path "styles/original.php" and that the menu name in editor is "Original". I hope this will lower the treshold to try out new styles. It will make updating EE also easier because style definitions are so simple.

Other stuff

- Some bugs fixed, e.g. settings' style menu not showing the selected style.
- Some editors in Multieditor will change to more like path editors are now.
- new styles and frames
- camera data fields "n/a", "none", "unknown" are ignored.

[cultrix]

Here is a partial wish list of mine. :-)

1. A link to go Home page or a particular page.
2. Sort Exhibition list on list.php in descending order of ID (ideal would be in the same arder as index.php)
3. Suppressing Thumb & microthumb images while adding a new exhibition. (My path has 1500 images & and takes a while for the page to load after update)
4.Reversing messages in addall.php to show images added first and then images skipped. if that's not possible suppress images skipped. (again due to exhibition containig 1500 images)
5.Instead of one cell for the exhibitions in index.php a table with 3 columns for plain list no microthumbs. This comes in handy when I have many exhibitions and want to show them in plain list no microthumbs mode.

There are many many more but I will wait until the next major update.

Prahalad

[Pekka]

cultrix wrote:
Here is a partial wish list of mine. :-)

1. A link to go Home page or a particular page.

OK.

You can easily insert your own site navigation to EE with one navigation.php file inserted after tag.

2. Sort Exhibition list on list.php in descending order of ID (ideal would be in the same arder as index.php)

There is already something called "Exhibition order editor". Or do you mean in editor listings?

3. Suppressing Thumb & microthumb images while adding a new exhibition. (My path has 1500 images & and takes a while for the page to load after update)

I suppose you mean adding new photo. Would you like to have a choice to see e.g. a 4-column list of filenames instead, used in bold/colored type? There has to be something to choose from if I give a choice to not show thumbs.

4.Reversing messages in addall.php to show images added first and then images skipped. if that's not possible suppress images skipped. (again due to exhibition containig 1500 images)

I'll see what can be done.

5.Instead of one cell for the exhibitions in index.php a table with 3 columns for plain list no microthumbs. This comes in handy when I have many exhibitions and want to show them in plain list no microthumbs mode.

You mean just exhibition names in three columns? Can you post me a template of what you like to have?

There are many many more but I will wait until the next major update.

:) Please don't hesitate writing even big wishlists now. I helps me to know all wished features before I design bigger changes to the code.

[cultrix]

Hi pekka,
I tried to do quote * /quote but it kinda messed up the reply so replying without quote :-(

Re 1.
Hmmm. I did not know that. I am new to PHP. In fact I learnt it because of EE. Could you please elaborate.

Re 2.
No I did not mean the "Exhibition Editor". I meant the "Visit Exhibition" drop down box just below "Show photos from category" dropdown. It would be nice to sort them by ID desc or in the same order they are set in the "exhibition order editor"

Re 3.
No I meant when you click on "Create a new exhibition".
when you change " SELECT THUMB PATH..." and " SELECT MICROTHUMB PATH..." and update it updates thumbnails and microthumb images in the rightside cell. If you have a large amount of images this takes forever.

Re 5

Here is the template I was talking about.

Index Page

[Scho]

Would it be possible to add another field (or two) to camera data to provide info on filters used (eg. polarizer, UV, infrared, etc.) and lens extensions (eg. close-up attachments like 500D, tele extenders such as 1.4x or 2x, extension tubes)?

[Pekka]

cultrix wrote:
Re 1.
Hmmm. I did not know that. I am new to PHP. In fact I learnt it because of EE. Could you please elaborate.

With PHP you can include a file into any place of the code. The included command is replaced with contents of included file. See for example http://photography-on-the.net/ee/index.php . The top menu is included to the code of each page with command



it works without the variable "$page" of course



but I use there the "$page" variable to color each menu item based on what page we were on.

Here's the EE homepage's "top.php" in full:















">Index



">DoneÂ*andÂ*Todo



">Interface


">Editors


">Download


">Install Guide


">Online gallery

















Re 2.
No I did not mean the "Exhibition Editor". I meant the "Visit Exhibition" drop down box just below "Show photos from category" dropdown. It would be nice to sort them by ID desc or in the same order they are set in the "exhibition order editor"

But they should be in same order as in index page. If they are not there's a bug. In my gallery it works as it should....


Re 3.
No I meant when you click on "Create a new exhibition".
when you change " SELECT THUMB PATH..." and " SELECT MICROTHUMB PATH..." and update it updates thumbnails and microthumb images in the rightside cell. If you have a large amount of images this takes forever.


When those iframes load you can continue doing or click stop button on your browser. The thumbs are the as a visual confirmation of path contents. You don't have to wait they are loaded to continue editing.


Re 5

Here is the template I was talking about.

Index Page

http://www.cultrix.com/template.jpg


Ok, I'll do an indexpage choice like that for you.

[Pekka]

scho wrote:
Would it be possible to add another field (or two) to camera data to provide info on filters used (eg. polarizer, UV, infrared, etc.) and lens extensions (eg. close-up attachments like 500D, tele extenders such as 1.4x or 2x, extension tubes)?

Good that you reminded of that.

I'll add "accessories" table to database and multieditor, and you can select multiple accessories for each photo just like you select categories.

[Scho]

The accessories table idea sounds fine.

[ega1]

Pekka wrote:
If anyone has any wishes for next version of EE please let me know. Now is the time to write if anything bothers you or you know bugs or flaws in 1.22. This is not a big update, EXIF, upload, translation, rating etc are all coming later.


How about a way to suppress location and country output? Most of my images will be local, and it gets boring seeing the same location information all the time.

I'd like to be able to display this information selectively, the way technical detail is selectable now.

[Pekka]

ega1 wrote:
How about a way to suppress location and country output? Most of my images will be local, and it gets boring seeing the same location information all the time.

I'd like to be able to display this information selectively, the way technical detail is selectable now.


That's doable.

[HotDogOne]

Pekka, long time no speak, great work on EE :-)

would it be possible to have the new image selection screen show the most recently added images to the thumbs/microthumbs directory first. At the moment when the screen comes up the photographs are listed chronologically, meaning that all of the photographs I have just added are at the bottom of the page (and last to load). Having them at the top andbeing first to load would make things a lot easier as I have approaching 300 photographs online now :-)

[Pekka]

HotDogOne wrote:
Pekka, long time no speak, great work on EE :-)

would it be possible to have the new image selection screen show the most recently added images to the thumbs/microthumbs directory first. At the moment when the screen comes up the photographs are listed chronologically, meaning that all of the photographs I have just added are at the bottom of the page (and last to load). Having them at the top andbeing first to load would make things a lot easier as I have approaching 300 photographs online now :-)

Hi Stephen!

Yes, I'm now coding to misc settings choice of listing type (thumbs, microthumbs,filenames) and order for photo selection. Later I'll add maybe paging there, too.

Pekka

[HotDogOne]

Cooooool -

You da man !

Thanks Pekka!

[Paulhuang]

Hi Pekka,

How about being abe to categorise the Exhibition index into groups? An index for all people gallery, another for landscape gallery etc. This is useful if you start to have quite a few galleries. The grouping can be in diferent pages.

The way I am thinking of doing now is to install EE into a few directories. Not sure if it will result in any conflicts.

Great work.

Cheers,
paul
www.naturestops.com

[Pekka]

paulhuang wrote:
How about being abe to categorise the Exhibition index into groups? An index for all people gallery, another for landscape gallery etc. This is useful if you start to have quite a few galleries. The grouping can be in diferent pages.

I have to think about this. I could make 'exhibition category' and then have possibility to group by category. But then in exhibition browser the dropdown should be changed to nested DHTML menu which I really don't like because compatibility issues.

I could start by having and option to show used photo categories in index page for each exhibition.

The way I am thinking of doing now is to install EE into a few directories. Not sure if it will result in any conflicts.

You also would have to use a separate database for each installation. The index pages could very well be build by hand to suit any presentation, sorting and grouping, it just needs a bit of PHP skill.


Great work.

Thanks!

www.naturestops.com

Nice shots!

I'm wondering a bit why you have thumbnail sized photos as microthumbs and full size photos as thumbnails there....
Of course everything is possible :) but that will eat a lot of bandwith on each listing.

[Paulhuang]

Hi Pekka.

I think I better learn some PHP. Separate database sounds like possible. I think my webhoster gives me a few.

Thanks for bringing to my attention that my thumbs are actually thumbs and thumbs are actually full size pictures. I didnt realise that at all. I guess I thought full size was bigger!

Keep up the good work.

Cheers,
Paul
www.naturestops.com

[Scho]

When adding a new image to an existing exhibition could there be a one button save after entering all relevant info? Currently, it is necessary (or is it?) to click three save buttons "Save Names, etc.", "Save Categories", and "Save Paths".

[Pekka]

Scho wrote:
When adding a new image to an existing exhibition could there be a one button save after entering all relevant info? Currently, it is necessary (or is it?) to click three save buttons "Save Names, etc.", "Save Categories", and "Save Paths".

"Save names etc" and "save categories" has been now combined. I'm now redesigning the photo editor layout. I could add save paths there too but I'd like to keep the save button as high as possible....

I also coded a nice solution to one old problem last night: now photo editor menus flash, mode, metering, support, aperture, ev, iso are dropdown menus and you can freely choose your own menu texts there by editing one simple configuration file.

Example of configurations:

make_mode ("Manual");
make_mode ("Av");
make_mode ("Tv");
make_mode ("Program AE")

make_metering ("Center-Weighted");
make_metering ("Evaluative");
make_metering ("Spot");
make_metering ("Partial");

etc.

If the selected photo has some value in database that is not in your custom menu, the menu shows that to you in the end of the menu, with the value it has in db so that you can add it to your menu if you wish:

example:

Center-Weighted
Evaluative
Spot
Partial
NOT IN MENU (Super Evaluative)

----

The new UI layout (one suggestion, very alpha stage) seen in Windows XP. The header is editable, despite its looks :)

http://photography-on-the.net/ee/misc/ee_pe_beta.gif

[HotDogOne]

That looks so much better :-) I really like the idea of the combined save button as well - will make things much quicker!

[Paulhuang]

HI Pekka,

How about automating the creation of the necessary directories on the server when I click on create new exhibition? Not sure if what I am asking is riddiculous but that will save the steps necessary now to create the directories manually.

Cheers,
Paul
www.naturestops.com

[toast_dk]

Hi Pekka,

I know this is a BIG one, but I need the gallery in DANISH !!!! :-O :-O :-O

I will of course do this manually (dreading the next update though!), but if at all possible, it would be COOL with some sort of central language-file.

/Steffen

PS: I am SO impressed with EE - Great job! :)

[pigasus]

Hi Pekka,

In multiarea navigation, could the central area (return to exhibition index) be made larger? I find that I miss it frequently. I think one expects to go close to the edges for the other options, so I think they could do with smaller areas.

Thanks,
Sally

[Pekka]

pigasus wrote:
Hi Pekka,

In multiarea navigation, could the central area (return to exhibition index) be made larger? I find that I miss it frequently. I think one expects to go close to the edges for the other options, so I think they could do with smaller areas.

Thanks,
Sally

I could put those ratios into database, but you can change them easily by hand, if you understand the "system" used.

In photo.php you see in around line 1000:

$w1 = intval(.4*$x); $w2 = intval(.2*$x); $w3 = intval(.4*$x);
$h1 = intval(.4*$y); $h2 = intval(.2*$y); $h3 = intval(.4*$y);


both lines have three values:

width line ($w1) has ".4", ".2" and ".4"

and

height line ($h1) has ".4", ".2" and ".4"

These numbers mean percent values calculated from width and height respectively. .4 is 40% and .2 is 20%, so the current setting means 40% for left, 20% for the middle and 40% for the right. 40% for top, 20% for the middle and 40% for the bottom.

You can change those values to anything as long as they add to 1 (100%) per line.

If you want a bigger middle area you can do it with

$w1 = intval(.2*$x); $w2 = intval(.6*$x); $w3 = intval(.2*$x);
$h1 = intval(.2*$y); $h2 = intval(.6*$y); $h3 = intval(.2*$y);

[pigasus]

Pekka wrote:
I could put those ratios into database, but you can change them easily by hand, if you understand the "system" used.


Thanks Pekka. I can do that easily enough. Only problem I have with modifying files is that they get overwritten with every new updated version.

Sally

[earl_damron]

I may have missed this in the replies, but has there been any mention of programmatically picking up EXIF data (hopefully that's the right term)?

IOW, providing a way to import all the technical data so it doesn't have to be entered manually (e.g., shutter, focal length, etc).

Thanks

[Pekka]

earl_damron wrote:
I may have missed this in the replies, but has there been any mention of programmatically picking up EXIF data (hopefully that's the right term)?

IOW, providing a way to import all the technical data so it doesn't have to be entered manually (e.g., shutter, focal length, etc).

Thanks

A full EXIF read solution is being coded as we speak (more about that soon), but meanwhile I could make EE read thumbnail EXIF, and if it exists it would let you import the data.

I don't know which programs preserve exif when exporting, apparently least PS6 and Imageready does not.

[Scho]

I don't know which programs preserve exif when exporting, apparently least PS6 and Imageready does not.

PS 7 will preserve the exif data for jpegs saved using your action for creating files for import to EE, except for the thumb and microthumb files where exif data is lost. I think exif is not retained for the latter two because "Save for web" was used in the action for export.

[toast_dk]

I'm currently adding almost 400 photos to my database, and it would REALLY be cool, if the 'category' drop-downs were alphabetized, or (maybe even better) editable.

/Steffen

[Pekka]

toast_dk wrote:
I'm currently adding almost 400 photos to my database, and it would REALLY be cool, if the 'category' drop-downs were alphabetized, or (maybe even better) editable.

/Steffen

That is possible to have in next version, or the one after that :)

[toast_dk]

and another thing: Greenland is missing in the database.

[malum]

I don't know how easy this would be, it may already be possible I haven't had a good look yet. But it would be nice to be able to search for multiple things at once. i.e all the photos of animals taken in the USA or all the photos taken with a certain camera and a certain lens of landscapes.

just a thought

[Pekka]

malum wrote:
I don't know how easy this would be, it may already be possible I haven't had a good look yet. But it would be nice to be able to search for multiple things at once. i.e all the photos of animals taken in the USA or all the photos taken with a certain camera and a certain lens of landscapes.

just a thought

I think what you want is already there. There are three basic tools: search phrase, category, and sorting.

You can do a search for country "port" and select category "animals" and you will get all animal photos from portugal sorted by any criteria.

Same thing with lenses and cameras: search a lens "70-" and select category "landscapes" and then sort with any criteria.

I could do a very advanced search page later, but I think with current features you will get the photo you need quite easily - do you agree?. Main point with current system is that it is very fast - adding multiple search criteria would slow this down a lot.

Note also that with detail lists you can sort _each_ result page separately by clicking column headers. When you click next page the sorting is back to what's selected on top.

[malum]

I see what you are saying and I think a more complex search would not suit most of your users, I was just being selfish in that I want to use the software for a different purpose than most other people and having a complex search would be useful for me.

However I don't expect you to implement stuff that would only be useful to me (unless I pay you large sums of cash of course ;-) )

[malum]

Camera Support : Bank Manager

I like it

[Pekka]

malum wrote:
I see what you are saying and I think a more complex search would not suit most of your users, I was just being selfish in that I want to use the software for a different purpose than most other people and having a complex search would be useful for me.

However I don't expect you to implement stuff that would only be useful to me (unless I pay you large sums of cash of course ;-) )

Can you give me an example of a search you'd like to do and is NOT possible with EE now. If I know exactly what you want abd why you may see it in EE in some form some day.

[Pekka]

By the way, next EE will have an online help system in editors - place the cursor on any item on page and after one second a popup help appears explaining what that item is for - move the mouse away or click it and the popup disappears. Help system is linked to forthcoming multilanguage features.

Also, a snapshot type backup (to database, file, or text) is almost finished. You can do backup by pressing a button and restore backups from a menu (each backup is datetime stamped). The backup script is a generic one, which means it analyzes the database and builds backup specifically for that info - so I think it can be used to backup any MySQL database. The backup script is also designed to work with very big databases, which means you should not encounter any timeouts or 'mysql connection lost' problems like in conventional methods (phpMyAdmin comes to mind). Also, the backup code is so fast it could be built into editors as a permanent UNDO system with desired disk quota (later).

[malum]

Can you give me an example of a search you'd like to do and is NOT possible with EE now. If I know exactly what you want abd why you may see it in EE in some form some day.

Unfortunately I can't give you an example of a search that I can't do as I haven't looked into it far enough yet, sorry :D. It just looked like for instance that I wouldn't be able to produce a page with all the bronzes from the ming dynasty made by Hu Wenming for instance.
It may well be possible right now.

By the way do you have a release date for the next version? I only ask as if it is very soon I won't change all the php files that I need to until the new one is out.

many thanks

[toast_dk]

malum wrote:
By the way do you have a release date for the next version? I only ask as if it is very soon I won't change all the php files that I need to until the new one is out.
I've got the same "problem": Eager to start customizing, but if an upgrade is just around the corner ...

/Steffen :p

[malum]

By the way do you have a release date for the next version? I only ask as if it is very soon I won't change all the php files that I need to until the new one is out.

Bump (sorry)

[Pekka]

Sorry for being so quiet - I've been really busy with many things and this is the last week of my summer vacation and the weather is great.

The database backup system took a bit longer to code than I anticipated as it grew more sophisticated by the time I coded it. The rest of the new EE is much simpler stuff to finish, so I suppose it will be out in a week or so.

If you need to do modifications there is actually never a perfect time to do them, as with next version you wil need to rewrite mods again. Such is life.

[malum]

Many thanks. I will wait for the next before modding (fairly busy anyway).
waiting means more time before having to do it again.

[Taligent]

Hello Pekka!

I was reading up on PHP and mySQL because (you guessed it) I needed a GOOD photo gallery system and couldn't find one - until I found EE. It's great, I love it, thank you very much... :)

I've been able to modify the base code to accomplish pretty much everything I need it to, but here are a few feature requests that would make EE perfect - this would be for my use as a general purpose, personal photo gallery without multiple user contributions and other considerations of a large photo sharing site.

And now switching to extra-critical mode - some feature requests:

1) All fields search. While it's good that viewers can search specific fields for what they're looking for, a search that runs across all fields would be very useful if a viewer is unsure in which field a desired keyword would be found. The fields searched by an all fields search could be customized to avoid searching unnecessary fields, or disabled for large sites where searches would be prohibitively expensive in processing cycles and RAM. Or at least, could the Free Text field be added to the current search's categories?

2) Nested exhibitions. This is the only lacking feature that keeps me looking around for other scripts such as Gallery for a photo gallery solution (except that I don't care for Gallery's overall look and feel). This is currently possible with multiple databases in some fashion, but this only allows a single nested system. This is also a problem with webhosts that permit only a limited number of databases. For example, on your gallery it would probably be nice if you could have two top level exhibitions, one for the user contributed set of exhibitions and one for your personal set of exhibitions. This is an obvious example of course but overall this feature would be a REALLY REALLY REALLY nice thing. Really. Please? :)

3) Change the default header. Currently, when a photo is added with a blank header (set to blank by the photoeditor defaults) a header is automatically generated based on the filename and results in the format:

(filename.ext)

One very quick way to save a lot of work in retitling photos would be to generate a header in the format:

Filename

This would be useful in cases where the filename is considered adequate for the photo (snapshots, something not requiring a detailed description, etc) and where the author has no intention of adding other information to the photodata. Essentially, this would allow EE to be used as a quick and beautiful gallery generator where a user could set default photodata, and then simply add a group of photos to an exhibition and have an aesthetically acceptable, instant gallery without having to go through every single photo manually.

4) Along the same lines, addition of a group of photos without having to add one photo first. Currently, in a minimal workflow, the author needs to create a new exhibition, set default photodata, create a new photo, and in the new photo dialog can add all of the other photos in one batch. The problem with this is that the header information for the first opened is empty and when the author clicks save, it stays empty - no automatic generation of a header based on filename occurs as it does with all of the batch added photos. It would be nice to have a direct link in the "edit photo" page to add all unused photos, rather than hidden until a single photo is added first.

5) Shutterfly integration. This is fairly easy to do and I've already set it up on my gallery (I'll post a link whenever I finish tweaking it and get it onto a webhost). Shutterfly will integrate very well if sent a link to an image, height, width, and thumbnail image. This allows for users to click a link while on a photo page and have it added directly to a Shutterfly cart. With the gallery I am setting up, each photo is stored in folders as:

microthumb
thumb
small
medium
large
4x6
8x10

On every photo size view, there are two links on the page as - Order 4x6 or Order 8x10. Theoretically there could be a single link that sends the largest available image to Shutterfly and that could be resized down to 4x6 or whatever desired, but it's a little excessive bandwidth wise when most people will be printing 4x6's. The system I'm currently using is a hack because the height and width for the shutterfly link is hardcoded, and I set a variable in photodata for the path to the originals. Ideally, EE would determine the largest copy of the currently viewed image available, determine that image's dimensions, and create a link to shutterfly.

Chances are the other photofinishers will get the hint and start adding open interfaces as Shutterfly, and will probably require the same basic information, so this would not be a highly proprietary feature.

6) "View Size" cookie. This is something that I probably wouldn't have missed except that Photo.net uses it and I liked it - most users have a consistent preference for a certain photo size, and it would be nice if EE could write a cookie and maintain that preference between sessions.

7) Multiple photodata editing. I think this would require a new editing page. For example, suppose that I would like to change the location of "Large" images. Currently I would need to individually edit each photo and change the path to the new location. It would be extremely convenient if a page could be presented with the available photodata fields, and a list of photos in the exhibition. Each photo could have a selection check box, or be selected in a combo box. A photodata field - such as path for "Large" images - could be set to the new desired location, and then have that change applied to all of the selected photos. An interface like FileMan ( http://www.gossamer-threads.com/scripts/fileman/screenshots.htm ) would be wonderful.

*whew*

That's quite a bit more than I intended to write, but hopefully you understand that these are the things that would only add to something that is quite excellent as is. I appreciate the work you're putting into this project as you're fulfilling what would otherwise be a void - and without which I'd be having to slave away in notepad on a photo gallery. Thanks!

-Nikhil

[Pekka]

Taligent wrote:

1) All fields search. While it's good that viewers can search specific fields for what they're looking for, a search that runs across all fields would be very useful if a viewer is unsure in which field a desired keyword would be found. The fields searched by an all fields search could be customized to avoid searching unnecessary fields, or disabled for large sites where searches would be prohibitively expensive in processing cycles and RAM. Or at least, could the Free Text field be added to the current search's categories?

As it works now, all the parameters in search, sort and amount form are placed into one query, which is why the EE SQL part is very fast (e.g. 0.007 secs to get all main info for list.php). To do a full search would mean doing several sub searches, combining their results and the sorting them and paginating them. As this is perfectly doable a feature like this is best put on a separate interface - not only for speed but not many people need such detailed searches I think. Full search is one of the features to come for sure, though!

2) Nested exhibitions. This is the only lacking feature that keeps me looking around for other scripts such as Gallery for a photo gallery solution (except that I don't care for Gallery's overall look and feel). This is currently possible with multiple databases in some fashion, but this only allows a single nested system. This is also a problem with webhosts that permit only a limited number of databases. For example, on your gallery it would probably be nice if you could have two top level exhibitions, one for the user contributed set of exhibitions and one for your personal set of exhibitions. This is an obvious example of course but overall this feature would be a REALLY REALLY REALLY nice thing. Really. Please? :)

I have plans for this and have a db and logic scheme for it, all I need to code it. let's see what happens. I personally don't like Gallery's way of browsing, but of course I will do what people want. The only real problem is how to replace the list.php exhibition chooser menu with a nested one. I hate all browser incompatibilies and enormous chunks of code you need to do for a simple nested menu (and usually it is not fully compatible no matter how much code you put into it).

3) Change the default header. Currently, when a photo is added with a blank header (set to blank by the photoeditor defaults) a header is automatically generated based on the filename and results in the format:

(filename.ext)



I was in the impression the default header is taken from default photodata header?

One very quick way to save a lot of work in retitling photos would be to generate a header in the format:

Filename

This would be useful in cases where the filename is considered adequate for the photo (snapshots, something not requiring a detailed description, etc) and where the author has no intention of adding other information to the photodata. Essentially, this would allow EE to be used as a quick and beautiful gallery generator where a user could set default photodata, and then simply add a group of photos to an exhibition and have an aesthetically acceptable, instant gallery without having to go through every single photo manually.

This is very easy to do, but I never thought of it because I never rename files and CRW_000012321.jpg is much less meaningful to me than "New photo". I'll try to code your wish as a choice to default editor.

4) Along the same lines, addition of a group of photos without having to add one photo first. Currently, in a minimal workflow, the author needs to create a new exhibition, set default photodata, create a new photo, and in the new photo dialog can add all of the other photos in one batch. The problem with this is that the header information for the first opened is empty and when the author clicks save, it stays empty - no automatic generation of a header based on filename occurs as it does with all of the batch added photos. It would be nice to have a direct link in the "edit photo" page to add all unused photos, rather than hidden until a single photo is added first.

As I said, I wonder why the default name does not work in your system - here I get a default name when I add a new photo. Anyways - I sort of "hide" and "separated" the add all link because I really don't want people to push it by accident.

5) Shutterfly integration. This is fairly easy to do and I've already set it up on my gallery (I'll post a link whenever I finish tweaking it and get it onto a webhost). Shutterfly will integrate very well if sent a link to an image, height, width, and thumbnail image. This allows for users to click a link while on a photo page and have it added directly to a Shutterfly cart. With the gallery I am setting up, each photo is stored in folders as:

microthumb
thumb
small
medium
large
4x6
8x10

On every photo size view, there are two links on the page as - Order 4x6 or Order 8x10. Theoretically there could be a single link that sends the largest available image to Shutterfly and that could be resized down to 4x6 or whatever desired, but it's a little excessive bandwidth wise when most people will be printing 4x6's. The system I'm currently using is a hack because the height and width for the shutterfly link is hardcoded, and I set a variable in photodata for the path to the originals. Ideally, EE would determine the largest copy of the currently viewed image available, determine that image's dimensions, and create a link to shutterfly.

This is a good idea. Only thing I wonder about is that if supporting just one business is "wise" - at first I'd like to see just an order form from visitor for YOU, and only later add commercial services to the target list. Of course, if you have coded most of it already it could be nice to discuss details of it in email.

Chances are the other photofinishers will get the hint and start adding open interfaces as Shutterfly, and will probably require the same basic information, so this would not be a highly proprietary feature.

I'll see if I can contact some photofinishers and see if they can set up some integration with EE.


6) "View Size" cookie. This is something that I probably wouldn't have missed except that Photo.net uses it and I liked it - most users have a consistent preference for a certain photo size, and it would be nice if EE could write a cookie and maintain that preference between sessions.

I have had a strict "no cookies" rule when coding EE - cookies cause SO much trouble (just look at PHP mailing lists) that relying on them is not wise. Of course, keeping size in a cookie and then loosing the cookie or not accepting it is harmless, but nevertheless "do you want this cookie" questions are a PitA and not good gor software image. Also, image size can be so varied the chosen size does not stay across gallery anyway. This is why I'll put this on todo, but not very high.

7) Multiple photodata editing. I think this would require a new editing page. For example, suppose that I would like to change the location of "Large" images. Currently I would need to individually edit each photo and change the path to the new location. It would be extremely convenient if a page could be presented with the available photodata fields, and a list of photos in the exhibition. Each photo could have a selection check box, or be selected in a combo box. A photodata field - such as path for "Large" images - could be set to the new desired location, and then have that change applied to all of the selected photos. An interface like FileMan ( http://www.gossamer-threads.com/scripts/fileman/screenshots.htm ) would be wonderful.

Global photo editor commands are already on todo list. Especially path related commands need full coverage.

That's quite a bit more than I intended to write, but hopefully you understand that these are the things that would only add to something that is quite excellent as is. I appreciate the work you're putting into this project as you're fulfilling what would otherwise be a void - and without which I'd be having to slave away in notepad on a photo gallery. Thanks!

-Nikhil

I appreciate it very much that you took time to write this post. Wishes and ideas are always welcome and I try to make EE for the people who use it.

[Taligent]

Pekka wrote:
As it works now, all the parameters in search, sort and amount form are placed into one query, which is why the EE SQL part is very fast (e.g. 0.007 secs to get all main info for list.php). To do a full search would mean doing several sub searches, combining their results and the sorting them and paginating them. As this is perfectly doable a feature like this is best put on a separate interface - not only for speed but not many people need such detailed searches I think. Full search is one of the features to come for sure, though!

Sounds good.

I personally don't like Gallery's way of browsing, but of course I will do what people want.

Neither do I. It's functional but barren and not something that looks particularly easy to customize.

I hate all browser incompatibilies and enormous chunks of code you need to do for a simple nested menu (and usually it is not fully compatible no matter how much code you put into it).

Funny enough I used to hate Netscape because it was far more annoying about table rendering than IE. When I started fitting EE into my site I ended up hating IE for a very random and frustrating table rendering bug that Netscape had no problems with at all. I spent five hours resolving this issue. Good luck on the menu. If it helps, perhaps not all people will need the list.php Exhibition browser drop down box. I removed it completely. *shrug*


I was in the impression the default header is taken from default photodata header?

This is very easy to do, but I never thought of it because I never rename files and CRW_000012321.jpg is much less meaningful to me than "New photo". I'll try to code your wish as a choice to default editor. As I said, I wonder why the default name does not work in your system - here I get a default name when I add a new photo.

I setup a new database and installation of EE to make sure this was an actual event and not a product of modification. The default header setting in the default editor works fine EXCEPT when I set the default header to a blank box. An example to replicate this:

1) Create new exhibition.
2) Set paths for this exhibition.
3) Set defaults for photodata.
For default header, clear the box completely.
4) Add one photo to exhibition.
EE will properly assign a blank header to this photo.
5) From this add photo page, click Add unused photos.
6) Upon inspection of all of the subsequently added photos, the header will not be blank as it should be. Instead, the headers will contain the filename in format (filename.ext) and call this the header.

I'm not sure how to think about this. On one hand it's important that if you set a default header to blank that all photos actually inherit a blank header. On the other hand it would be very useful to have EE automatically generate a header based on the file name. I'm actually a film & film scanner user, so my filenames can serve as reasonable headers.

This is a good idea. Only thing I wonder about is that if supporting just one business is "wise" - at first I'd like to see just an order form from visitor for YOU, and only later add commercial services to the target list. Of course, if you have coded most of it already it could be nice to discuss details of it in email.

I'll see if I can contact some photofinishers and see if they can set up some integration with EE.

Shutterfly integration is extremely simple. I'm surprised that their design team had the presence of mind to create something so useful. The code:












I've emailed Shutterfly to find out more information about this technique as there is nothing available on their website. I only discovered this through Gallery and MyPhotoGallery, I am unsure where credit is due though. The fields that need to be changed on a per photo basis are:

returl
imraw
imrawheight
imrawwidth
imthumb

The referid and imbkprnt fields have no end result on the prints ordered (set to anything). Hopefully they'll reply with some useful information in their email, such as whether Shutterfly will attempt color correction and sharpening on photos uploaded through this method. There is an option to disable this extraneous processing through the native Shutterfly system but I have no idea what occurs with this sort of direct connection. This code works fine as it stands, however. I love it as users do not need to download and reupload images to have prints made, and the ordering cart integrates perfectly with the photo gallery by linking directly back to the gallery. No popups, redirections, or other such nonsense. It's too good to last for very long. :)

Global photo editor commands are already on todo list. Especially path related commands need full coverage.

Excellent. As I'm just now setting up the gallery system this is just a convenience - but later when I want to move images to different servers and have a hundreds of photos to update paths for individually......major headache.

Oh, another thought. Could you keep a log of exact code changes between versions? Most of the modifications I've made are purely cosmetic and I haven't had a need to modify the code that makes EE work (thanks to its wonderful flexibility). It would be a real time saver to be able to manually update specific sections of code, as this would usually be smaller than the cosmetic modifications. There are limits to the feasibility of this but for the minor stuff it would be great. If this would entail quite a bit of work, no need to go for it, I imagine that this would cater to perhaps 5% of the people who use EE.

Thanks,
Nikhil

[jonday]

Hi Pekka

I agree with the comments and suggestions re some form of integration to allow printing of photos from EE.

Although, the Shutterfly option works well and seems quite easy to implement, I would like to see as a minimum at the outset a second option of an order system which simply sends an email order to the album owner with the photo ref, size, name, address etc.

This would allow for people to either print their own photos for sale. Also, in the UK, Shutterfly is not really an option and good alternates like colourmailer.com do not have a similar integration option.

I have a local digital lab who are very happy to print out photos that are emailed to them. Rather than design lots of different integrations, a solution that simply sends the order request from the gallery by email to the gallery owner would be great.

The next step from that would be to have an option to include the full size original file with the email and have an option of where to deliver the email - e.g. a user could visit my site, order a photo, provide their address details and payment details, and then an email would be send to me and copied to the local photo labs email.

Would this not allow for more flexibility for people to build up from this basic solution as required?

Thanks

[Taligent]

A Shutterfly rep. was helpful and provided the following info:

http://www.taligentx.com/shutterfly/

Also, some guidelines for this service:

Guidelines for C for P Partners


The following are general guidelines for use with C for P partners. These are necessary for the success of these partnerships.

• Shutterfly currently only prints .JPG images. Partners must prevent non-JPG images from being selected for posting to the C4P service.
• Images must be of high quality and high resolution. As resolution is a key component to the overall outcome of the pictures, we STRONGLY recommend using the highest resolution possible and absolutely nothing smaller than 1024x768 (or a minimum of 200 dpi). Images with a resolution below what is recommended will be blocked from the order path.
• Images must be a certain shape and aspect ratio (1.33:1) as non-standard size images (e.g., square or panoramic) will be subject to undesirable cropping, or will be printed whole with white borders added, depending upon the shape of the image. If odd sized images are used, you will need to inform your customers the pictures they receive may be cropped, or contain a white border.

• Images must remain archived and available 24 hours a day, seven days a week. Image URLs must be maintained for 60 days after images are removed from the site. Modifications to the archive or gallery that result in changes to image URLs will cause problems for orders in process and for reprints.
• The image URLs passed to Shutterfly C4P server must never be reused for different images (else Shutterfly could pull an image from its C4P cache thinking the new order is a reorder for a previously printed image).
• Our system must be able to access image URLs on the host server without password restrictions or other barriers.

• Shutterfly will need contact information for the person running the gallery, in the event of a problem.

• Shutterfly requires 2 separate URL’s for each image, one for the raw image and one for the thumbnail of that image.

• Shutterfly requires you have sufficient bandwidth relative to volume.

• Support for customer's website belongs to the customer - we can provide support only for the c4p ordering path itself.


I also had a few specific questions about how Shutterfly operated in this particular mode:

Nikhil -

Thank you for contacting Shutterfly. It sounds like you are speaking
about our click-4-prints system. I will send you the requirements and
implementation of the system on your own server.

If you use the C4P system, Shutterfly does not transfer the images when
you click order. When Shutterfly is ready to print the image it will
grab them and print from your server. Therefore if your server is down
or the image are unaccessible Shutterfly will not be able to print your
order.

The VividPics technology will not be able to be turned off if you use
the C4P platform.

Images are converted in sRGB and printed in the sRGB colorspace. You may send the AdobeRGB images, but they might look slightly different.
Therefore you may convert them to sRGB if you wish.

Please let us know if you have any additional questions.

Sincerely,

Tim
Shutterfly Customer Service
customerservice@shutterfly.com

The unfortunate end result however is that automatic color enhancement and sharpening cannot be disabled (VividPics). This disqualifies Shutterfly as a good photofinishing option for direct ordering. Very sad. I'll email back and request that a tag be added to the input form to disable VividPics. I have a feeling it's something that people who would be interested in such integration would like to have control over. If enough complain...

A more generalized ordering system would indeed be very useful for the more serious photographers, as you could set pricing, control customer service, etc. Personally, I was looking for a seamless integration that I did not have to deal with at all, as the majority of the images of interest would be simple snapshots for friends and family. The thought of manually dealing with the requests....no fun.

As Shutterfly is also charging double the rate of common Fuji Frontier based photofinishers (Walmart...yes, Walmart) without using at least the pro Crystal Archive papers - it's even less attractive.

Pekka, if you hear from any other photofinishers about integration options....please tell! :)

-Nikhil