Menu
▾
▴
ids-devel
|
From: timduru <ti...@ti...> - 2003-07-29 12:28:08
|
Hi , Just thought I would send a small message about some of the modifications I made, well overall I'd like to say that IDS works quite well and it's really very useful for my site :) Over the years I've made quite a few modifications, I think a few users could be interested by some of them. Some are just bug fixes,speed optimizations, and a few new features and enhancements. You can see the modified version running there: http://fursuit.timduru.org/view/ It's based on 0.81 but it shouldn't be too difficult to incoporate the modification made from 0.82 I'm not even sure to remember everything I've modified and to get a full list I would have to make a more detailled diff with the original source code. You know how it is, most of them were quick hacks 'on the fly' but they work fine ;o) But I'll list some of the modifications I remember of below: + exif problem, when an image had exif info into it, the thumbnail was including the exif data and so making it like 30KB too big. (that one was really making dialup user yell ;o) ) + speed optimization in non date sorting mode, (as it was sorting by date first even in name sorting mode, and that can be quite slow on a few thousands pictures directories) From what I've tested it can be about 15x faster for large albums if you don't sort by date. 2x only if you sort by date. + a few 'software errors' problem fixed, like it doesn't stop even if one picture is corrupted, but keep displaying the albums. + pretty url system that one needed quite some rewriting all around in the code, but that was one of the biggest complaint I was getting from the users: that the urls were not really friendly. with the new system the url is just like browsing regular directories and you can just append ',imagename' to see an image. (have a look at the online site) + possibility to just put a file in an html file in the directory corresponding to an album, so that the content is included and displayed in the album (it's useful to me as I allow both the image archive to be browsed by IDS and raw apache directories, I then configured apache to display the same html file IDS is now using as the header of the directory, so I don't have to enter the comments twice) + CGI::Cache compatible to speed up things, (well it's not configurable it's either include the code or comment it so far, but it's located at the very beginning of the code) I've tested it for some time and it worked quite well and were making things faster. But I then removed it as I update my page quite often, so having it cached too much was not the best in my case. + added the display of the first filename of a subpage after the page1...2..3.. at the bottom of the album + added next and prev page links + search function was not working with symlinks + cookie changed a bit to make it work with multiple virtual hosts, seems to be working , but might need some more debugging .. some of the modifications / features are in the config file, some others would need some more cleaning to be incorporated. It might also need some customization for general use as some of them are quite focused on the way I use it for my site. Well let me know if there is some interest in all these modifications. ;) Timduru |
|
From: Chris S. <chr...@ya...> - 2003-07-30 02:03:53
|
I'd love to see these incorporated into IDS. Chris --- timduru <ti...@ti...> wrote: > Hi , > Just thought I would send a small message about > some of the modifications I made, > well overall I'd like to say that IDS works quite > well and it's really very useful for my site :) > > Over the years I've made quite a few modifications, > I think a few users could be interested by some of > them. > Some are just bug fixes,speed optimizations, and a > few new features and enhancements. > > You can see the modified version running there: > http://fursuit.timduru.org/view/ > > It's based on 0.81 but it shouldn't be too difficult > to incoporate the modification made from 0.82 > > > I'm not even sure to remember everything I've > modified and to get a full list I would have to make > a more detailled diff with the original source code. > You know how it is, most of them were quick hacks > 'on the fly' but they work fine ;o) > > But I'll list some of the modifications I remember > of below: > > + exif problem, when an image had exif info into it, > the thumbnail was including the exif data and so > making it like 30KB too big. (that one was really > making dialup user yell ;o) ) > > + speed optimization in non date sorting mode, (as > it was sorting by date first even in name sorting > mode, and that can be quite slow on a few thousands > pictures directories) > From what I've tested it can be about 15x faster for > large albums if you don't sort by date. > 2x only if you sort by date. > > + a few 'software errors' problem fixed, like it > doesn't stop even if one picture is corrupted, but > keep displaying the albums. > > + pretty url system > that one needed quite some rewriting all around in > the code, but that was one of the biggest complaint > I was getting from the users: that the urls were not > really friendly. > with the new system the url is just like browsing > regular directories > and you can just append ',imagename' to see an > image. > (have a look at the online site) > > + possibility to just put a file in an html file in > the directory corresponding to an album, so that the > content is included and displayed in the album > (it's useful to me as I allow both the image archive > to be browsed by IDS and raw apache directories, I > then configured apache to display the same html file > IDS is now using as the header of the directory, so > I don't have to enter the comments twice) > > + CGI::Cache compatible to speed up things, (well > it's not configurable it's either include the code > or comment it so far, but it's located at the very > beginning of the code) I've tested it for some time > and it worked quite well and were making things > faster. > But I then removed it as I update my page quite > often, so having it cached too much was not the best > in my case. > > + added the display of the first filename of a > subpage after the page1...2..3.. at the bottom of > the album > + added next and prev page links > + search function was not working with symlinks > + cookie changed a bit to make it work with multiple > virtual hosts, seems to be working , but might need > some more debugging .. > > some of the modifications / features are in the > config file, some others would need some more > cleaning to be incorporated. > > It might also need some customization for general > use as some of them are quite focused on the way I > use it for my site. > > Well let me know if there is some interest in all > these modifications. ;) > > Timduru __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Jean-Marc U. <uj...@gm...> - 2003-08-05 20:49:44
|
Hello
My problem wirh IDS ist this one:
> + exif problem, when an image had exif info into it, the thumbnail was
including the exif data and so making it like 30KB too big. (that one was
really making dialup user yell ;o) )
How do you changed it ? I think it was not so difficult !
Thanks a lot !
Jean-Marc
http://www.ulrichs.ch
|
|
From: timduru <ti...@ti...> - 2003-08-11 13:07:48
Attachments:
EXIF.txt
|
> My problem wirh IDS ist this one: > > > + exif problem, when an image had exif info into it, the thumbnail > > was > including the exif data and so making it like 30KB too big. (that one > was really making dialup user yell ;o) ) > > How do you changed it ? I think it was not so difficult ! > > Thanks a lot ! I modified the createDisplayImage method What I do is first create a blank image with no EXIF then copy the current image data into that one. Maybe there another solution with imageMagick I'm not really an expert with it .. ;) I've attached the new version with this message. It also removes the overlay icon on the thumb if I remember well as I didn't really need it, if you want it back you'll have to uncomment some of the lines. let me know if it works for you.. thanks |
|
From: Techwolf <Tec...@at...> - 2003-08-11 17:59:49
|
On Mon, 2003-08-11 at 08:03, timduru wrote: > > I modified the createDisplayImage method > What I do is first create a blank image with no EXIF then copy the current image data into that one. > Maybe there another solution with imageMagick I'm not really an expert with it .. ;) > > I've attached the new version with this message. > It also removes the overlay icon on the thumb if I remember well as I didn't really need it, > if you want it back you'll have to uncomment some of the lines. > Can you re-post that as a diff -u? I don't know what diff program you used there as I can't use that type of patch. Also, the "+" overlay on the thumbs can be turned off in the settings, no patch is needed. -- Techwolf Tec...@at... http://www.techwolf.net/index.html PGP public keys on web site. <html> <form> <input type signature> </form> </html> |
|
From: timduru <ti...@ti...> - 2003-08-11 21:47:46
|
> On Mon, 2003-08-11 at 08:03, timduru wrote: > > > > I modified the createDisplayImage method > > What I do is first create a blank image with no EXIF then copy the current image data into that one. > > Maybe there another solution with imageMagick I'm not really an expert with it .. ;) > > > > I've attached the new version with this message. > > It also removes the overlay icon on the thumb if I remember well as I didn't really need it, > > if you want it back you'll have to uncomment some of the lines. > > > > Can you re-post that as a diff -u? I don't know what diff program you > used there as I can't use that type of patch. well it's not a patch it's called copy-paste ;) just open the idsShared.pm with your favorite text editor and replace the entire createDisplayImage function Sorry but I'm just too busy for the moment with other things to go more in details and put back the overlay / do the patch against 0.82, test against 0.82 and look more in details... I don't think 0.82 modified something in the createDisplayImage function compared to the 0.81 version I'm using but just in case backup your original idsShared.pm file. ;) |
|
From: Ashley M. K. <as...@pc...> - 2003-08-11 22:38:44
|
timduru wrote:
>well it's not a patch it's called copy-paste ;)
>just open the idsShared.pm with your favorite text editor
>and replace the entire createDisplayImage function
>
>
If you want your stuff integrated into the main stream application,
you need to supply diffs of what you're doing. Not everyone knows how
to edit those files, and not everyone has the guts to even touch stuff
they don't quite understand. Diffs are a lot easier to apply for a lot
of people, and will also make live for us developers a lot easier.
It doesn't matter what version you've "patched" up, current or old,
it can always be back (or fore) ported if needed, but you need to get
used to submitting diffs instead.
--
W | I haven't lost my mind; it's backed up on tape somewhere.
+--------------------------------------------------------------------
Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130
IT Director / SysAdmin / WebSmith . 800.441.3873 x130
Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave. #6
http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.
|
|
From: timduru <ti...@ti...> - 2003-08-12 08:41:59
|
> If you want your stuff integrated into the main stream > application, > you need to supply diffs of what you're doing. Not everyone knows how > to edit those files, and not everyone has the guts to even touch stuff > they don't quite understand. Diffs are a lot easier to apply for a > lot of people, and will also make live for us developers a lot easier. yes, but I thought juste replacing the function would be easier and more useable by JM Ulrich instead of having a diff that might fail. Replacing the entire function by hand seemed safer to me until I upgrade to 0.82 and make clean patches.. But JM found even a better solution :o) > It doesn't matter what version you've "patched" up, current or > old, > it can always be back (or fore) ported if needed, but you need to get > used to submitting diffs instead. Ok, well that's what I said in my first post, that if there was interest in some / all of the modifications that I would take the time to isolate most of them and make clean patches. But as I didn't really get many replies of interest, I just didn't do it yet. I preferred to deal with the ones who emailed me in private directly and give them my entire code and help them making the few configuration modifications. :) As I said in my first post, some of my modifications might not be of everyones interests, so I was more waiting for feedback / requests of what could/should be ported into the main stream. So what should I do ? make a huge diff on my version after including the 0.82 modifications ? Make one diff for all the small changes / bug fixes and another one for the pretty url modifications ? (as that last one is the modification that generates the most changes , might be better to have it separate ? ) or try to make one diff for every single change ? (might not be the easiest to integrate though, as diff after diff it'd get more and more difficult to merge as the code would change ? ) I'm not sure what you or others would prefer, what would be easier etc... Also Is there a way to make the diffs so that if applying one diff after the other it doesn't fail because the first diff have already modified the same file / code portion ? Do you still have the original ids-0.81.tgz btw ? I don't see it in the download area.. that way I could make a diff between 0.81 and 0.82 and include that in my version so I'm up to date with 0.82 to make the diffs on my modifications. thanks |
|
From: Ashley M. K. <as...@pc...> - 2003-08-12 09:41:37
|
timduru wrote:
>So what should I do ? make a huge diff on my version after including the 0.82 modifications ?
>Make one diff for all the small changes / bug fixes
>and another one for the pretty url modifications ? (as that last one is the modification that generates the most changes , might be better to have it separate ? )
>
>or try to make one diff for every single change ?
>(might not be the easiest to integrate though, as diff after diff it'd get more and more difficult to merge as the code would change ? )
>
Bug fixes and the such can be done in one diff file. I will revise
them and go from there. Keep in mind that some might have also made it
into 0.83b2, so it's a good idea checking that code base as well.
Enhancements should be submitted one at a time.
>Do you still have the original ids-0.81.tgz btw ? I don't see it in the download area..
>that way I could make a diff between 0.81 and 0.82 and include that in my version so I'm up to date with 0.82 to make the diffs on my modifications.
>
I'm made 0.81 active so you can download it.
--
H| I haven't lost my mind; it's backed up on tape somewhere.
+--------------------------------------------------------------------
Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130
IT Director / SysAdmin / WebSmith . 800.441.3873 x130
Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave. #6
http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.
|
|
From: Chris S. <chr...@ya...> - 2003-08-12 14:09:08
|
> But as I didn't really get many replies of interest, > I just didn't do it yet. > I preferred to deal with the ones who emailed me in > private directly and give them my entire code > and help them making the few configuration > modifications. :) Please don't take a lack of email replies on the list as a lack of interest. Most people aren't going to send "me too" emails, even if they'd like the changes you've made. Also, there are many people who might appreciate your changes being incorporated into the core IDS who aren't on this list, but will download upgrades to IDS and enjoy your new features. > As I said in my first post, some of my modifications > might not be of everyones interests, > so I was more waiting for feedback / requests of > what could/should be ported into the main stream. Post the bug fixes for sure. Also post the pretty URL fix. Those are the ones I'm most interested in seeing. Chris __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Techwolf <Tec...@at...> - 2003-08-12 18:44:53
|
On Tue, 2003-08-12 at 08:30, Chris Shaffer wrote: > Please don't take a lack of email replies on the list > as a lack of interest. Most people aren't going to > send "me too" emails, even if they'd like the changes > you've made. Also, there are many people who might > appreciate your changes being incorporated into the > core IDS who aren't on this list, but will download > upgrades to IDS and enjoy your new features. I second that. I'm quiet sure that there is no AOLmetooers here. That is one of the Internet pet peeves, 100 replies to a post with nothing but "me too" in it. Most of us here are smarter then that. :-) As far as what type of patches, go with what the developer suggested, all bug fixes in one patch. And individual enhancements in separate patches. This is so if one enhancements isn't going to work, the others won't get tossed out due to being in that one huge patch. Most patches for single file is diff -u, however, for packages like this one, I slightly different one is used, but it is the same format. I forgot the command for it, but it does an entire directory at once. And one more thing, please don't attachment the patch. I can't read it because my e-mail client doesn't know what to do with a file with no extension. Many other packages have rules that forbid attachments. Just place the patch text into the e-mail itself. Easiest way is a cut and paste operation. The reason for this is so developers on major packages can quickly read the patches from the hundreds of e-mail patch submissions. Having to spend 30 seconds to save, switch to another program, find the file, open it, then read and try to remember what the patch was about will get tiresome VERY fast. In most cases, like me, I usually have to save it in a different filename in order to keep track of it or use the right extension for rpm packaging that I do all the time. Quickest way is a cut and paste into the new file. Now that I have another Lunix box up, I may try to package IDS in a rpm format that is compatible with redhat and similar. Biggest problem is how the default web server is packaged. Redhat I am very familiar with. Mandrake very little, others are none. Can someone here point out a helpfull URL about doing patches? I remember seeing one good page, but I forgot where it is now. :-/ -- Techwolf Tec...@at... http://www.techwolf.net/index.html PGP public keys on web site. <html> <form> <input type signature> </form> </html> |
|
From: timduru <ti...@ti...> - 2003-08-12 20:12:11
|
ahh too late.. ;) well I don't know, as you pointed out before mail reader can wrap lines, so it might not be the best idea to paste it directly into the email message The safest is still the attachment I think. Or I could attach it with a .txt extension ? what does the developpers prefer ? On 12 Aug 2003 13:38:23 -0500 Techwolf <Tec...@at...> wrote: > And one more thing, please don't attachment the patch. I can't read it > because my e-mail client doesn't know what to do with a file with no > extension. Many other packages have rules that forbid attachments. > Just place the patch text into the e-mail itself. Easiest way is a cut > and paste operation. The reason for this is so developers on major > packages can quickly read the patches from the hundreds of e-mail > patch submissions. Having to spend 30 seconds to save, switch to > another program, find the file, open it, then read and try to remember > what the patch was about will get tiresome VERY fast. |
|
From: Ashley M. K. <as...@pc...> - 2003-08-12 20:21:39
|
timduru wrote:
>The safest is still the attachment I think.
>Or I could attach it with a .txt extension ?
>what does the developpers prefer ?
>
>
Safest is attachment, and while the .txt extension is okay, keep in
mind that some mailers will still include it in the message body
(however the ability to save the attachment to disk is still available.)
So with or without an extension, to me, doesn't matter. As for
attachments, personally I'm partial to them. I much rather have someone
point me to an URL containing a .txt file that I can grab. Reason being
is because I'm on some dev-lists where the diff attachments are just
large, and with several thousand list members, it becomes a huge
bandwidth hog. Seeing as how small your attachment was, it doesn't
matter really.
--
W | I haven't lost my mind; it's backed up on tape somewhere.
+--------------------------------------------------------------------
Ashley M. Kirchner <mailto:as...@pc...> . 303.442.6410 x130
IT Director / SysAdmin / WebSmith . 800.441.3873 x130
Photo Craft Laboratories, Inc. . 3550 Arapahoe Ave. #6
http://www.pcraft.com ..... . . . Boulder, CO 80303, U.S.A.
|
|
From: Techwolf <Tec...@at...> - 2003-08-13 03:56:12
|
On Tue, 2003-08-12 at 14:46, timduru wrote: > ahh too late.. ;) > well I don't know, as you pointed out before mail reader can wrap lines, > so it might not be the best idea to paste it directly into the email > message > The safest is still the attachment I think. > Or I could attach it with a .txt extension ? > what does the developpers prefer ? > > ARG!! *smack head* I totally phase it on the wrapping thing. I was thinking of what I've read on the net, totally forgetting the wrap. I've bet the developers didn't think about that problem. Gee, I can't win for loosing. :-) I think most mailers will handle .txt extension and display it inline. I think mine does. I use Evolution. -- Techwolf Tec...@at... http://www.techwolf.net/index.html PGP public keys on web site. <html> <form> <input type signature> </form> </html> |
|
From: Techwolf <Tec...@at...> - 2003-08-13 04:09:41
|
On Tue, 2003-08-12 at 14:46, timduru wrote: > ahh too late.. ;) > well I don't know, as you pointed out before mail reader can wrap lines, > so it might not be the best idea to paste it directly into the email > message I just realized, a wrapped diff -u can be easily seen where the wrapping occurred, due to all lines begin with space, +, or -. Though it could get a bit tricky with spaces near the wrap point. For small stuff, I think the attachment .txt would do, but it all depends of the developers of the program as what they prefer. I'm sure more then one technique is used. -- Techwolf Tec...@at... http://www.techwolf.net/index.html PGP public keys on web site. <html> <form> <input type signature> </form> </html> |
|
From: Jean-Marc U. <uj...@gm...> - 2003-08-11 21:24:45
|
Hello !!
I solved the problem now alone with a builtin function of Image:Magick:
I added in the function createDisplayImage at Line 606 to lines an then it
locks like this:
----------------------------------------------------------------------------
------------------------------------------------
$x = $imageToScale->Border(color=>'black',width=>$scaledImageBorderWidth,
height=>$scaledImageBorderWidth);
die "$x" if "$x";
$x = $imageToScale->Profile("*");
die "$x" if "$x";
if (($displayScaledIcon) eq 'y' && ($maxDimension eq
$previewMaxDimension)) {
my($overlayXSize, $overlayYSize) = $scaledOverlay->Get('width',
'height');
$imageToScale->Composite(image=>$scaledOverlay,compose=>'over',geometry=>("+
".($displayX - ($overlayXSize + $scaledImageBorderWidth))."+".($displayY -
($overlayYSize + $scaledImageBorderWidth)))); #overlay the scaled icon
}
----------------------------------------------------------------------------
------------------------------------------------
This change removes the EXIF and other infos in all rescaled images (thumbs
and all pics not in original size). This was exactly what I wanted.
See here:
http://www.ulrichs.ch/ids/index.cgi?mode=album&album=./Night%20in%20Bern
I found it here: http://www.imagemagick.org/www/convert.html#exam
Greetings
Jean-Marc
|
|
From: Techwolf <Tec...@at...> - 2003-08-12 05:25:32
|
On Mon, 2003-08-11 at 16:24, Jean-Marc Ulrich wrote: > Hello !! > I solved the problem now alone with a builtin function of Image:Magick: > > I added in the function createDisplayImage at Line 606 to lines an then it > locks like this: > > > This change removes the EXIF and other infos in all rescaled images (thumbs > and all pics not in original size). This was exactly what I wanted. > See here: > http://www.ulrichs.ch/ids/index.cgi?mode=album&album=./Night%20in%20Bern > > I found it here: http://www.imagemagick.org/www/convert.html#exam > > Greetings > > Jean-Marc > What file was changed? And what diff program did you use? I can't see the changes in it. -- Techwolf Tec...@at... http://www.techwolf.net/index.html PGP public keys on web site. <html> <form> <input type signature> </form> </html> |
|
From: Techwolf <Tec...@at...> - 2003-08-12 06:40:01
|
On Mon, 2003-08-11 at 16:47, timduru wrote: > > well it's not a patch it's called copy-paste ;) > just open the idsShared.pm with your favorite text editor > and replace the entire createDisplayImage function > Major problem with that. e-mail wraps at 72, what wrap did you set yours? This could very well hose the system because of different formating systems between editors. > > Sorry but I'm just too busy for the moment with other things to go more in details and put back the overlay / do the patch against 0.82, test against 0.82 and look more in details... > As soon I figure out what command to pass to Imagic, I can post a diff here. I'm sure I am not the only one that has this major bug that makes thumbnails 30-50K apiece. > I don't think 0.82 modified something in the createDisplayImage function compared to the 0.81 version I'm using > but just in case backup your original idsShared.pm file. ;) Doesn't matter, a diff you can see what is changed and can easily port it to later versions. I do this all the time with my custom redhat spec kernel builds that I add ACPI, Omnibook, and other patches along with redhat 1000+ patches. -- Techwolf Tec...@at... http://www.techwolf.net/index.html PGP public keys on web site. <html> <form> <input type signature> </form> </html> |
|
From: timduru <ti...@ti...> - 2003-08-12 08:17:43
Attachments:
diffExif
|
Techwolf <Tec...@at...> wrote: > Major problem with that. e-mail wraps at 72, what wrap did you set > yours? This could very well hose the system because of different > formating systems between editors. well I sent it as an attachment in a text file, If it wraps in the email you see it's because your email client is embedding the .txt attachment in the email then wrapping it. The best would be to save the attached text file then open it. > > Sorry but I'm just too busy for the moment with other things to go > > more in details and put back the overlay / do the patch against > > 0.82, test against 0.82 and look more in details... > > > As soon I figure out what command to pass to Imagic, I can post a diff > here. I'm sure I am not the only one that has this major bug that > makes thumbnails 30-50K apiece. well Jean-Marc Ulrich solution is much better than mine. I've attached the diff for his solution against 0.82 with this email. My changes included a few more things, but I'll post another diff later on including these, after I've moved to 0.82. that way it'd be easier. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X