| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
68593
|
Fri Apr 7 09:58:33 2017 |
 | christian | c_grebing@web.de | Question | Windows | V3.1.0-3c6435e | Re: Elog not see image magick | This I do not fully understand: To my understanding the PATH environment variable (includes the ImageMagick path) is a system variable and should be accessable from any account and should be valid under any conditions. Am I wrong? Additionally, I tried adding the system Path variable to the user specific variables for that user that runs the service (Path = %Path%) in the system settings. Finally, I tried copying the imdisplay.exe (ImageMagick executable) and convert.exe (used for the software detection) from the ImageMagick installation directory to the same directory as elogd. Neither of these approaches was successfull.
Christian
| Stefan Ritt wrote: |
|
Must be your PATH environment variable. You have usually different paths when running interactively or as a service. Try to change the path seen by services, or put the ImageMagick executable in the same directory as elogd.
Stefan
| christian wrote: |
|
Update:
While the image scaling via ImageMagick works when running elog manually it doesn't when running elog as a service. The service is hosted in the same user environment that allows image scaling with elog started manually. What else could go wrong?
Christian
|
|
|
|
68594
|
Fri Apr 7 10:22:03 2017 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | V3.1.0-3c6435e | Re: Elog not see image magick | I don't undersand myself fully how services see the environment. Like if they see the PATH at all. In some occations it helped to run the service not under the SYSTEM account, but under the (admin) account of a real user.
Stefan
| christian wrote: |
|
This I do not fully understand: To my understanding the PATH environment variable (includes the ImageMagick path) is a system variable and should be accessable from any account and should be valid under any conditions. Am I wrong? Additionally, I tried adding the system Path variable to the user specific variables for that user that runs the service (Path = %Path%) in the system settings. Finally, I tried copying the imdisplay.exe (ImageMagick executable) and convert.exe (used for the software detection) from the ImageMagick installation directory to the same directory as elogd. Neither of these approaches was successfull.
Christian
| Stefan Ritt wrote: |
|
Must be your PATH environment variable. You have usually different paths when running interactively or as a service. Try to change the path seen by services, or put the ImageMagick executable in the same directory as elogd.
Stefan
| christian wrote: |
|
Update:
While the image scaling via ImageMagick works when running elog manually it doesn't when running elog as a service. The service is hosted in the same user environment that allows image scaling with elog started manually. What else could go wrong?
Christian
|
|
|
|
|
68595
|
Fri Apr 7 10:24:31 2017 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | V3.1.0-3c6435e | Re: Elog not see image magick | Ah sorry. I recall now: Under Windows, calling subprocesses from a service does not work at all. After a couple of days of work I was not able to get this running. If somebody has some idea, I'm happy to try it. So most people use the elogd daemon in the background only under Linux.
Stefan
| Stefan Ritt wrote: |
|
I don't undersand myself fully how services see the environment. Like if they see the PATH at all. In some occations it helped to run the service not under the SYSTEM account, but under the (admin) account of a real user.
Stefan
| christian wrote: |
|
This I do not fully understand: To my understanding the PATH environment variable (includes the ImageMagick path) is a system variable and should be accessable from any account and should be valid under any conditions. Am I wrong? Additionally, I tried adding the system Path variable to the user specific variables for that user that runs the service (Path = %Path%) in the system settings. Finally, I tried copying the imdisplay.exe (ImageMagick executable) and convert.exe (used for the software detection) from the ImageMagick installation directory to the same directory as elogd. Neither of these approaches was successfull.
Christian
| Stefan Ritt wrote: |
|
Must be your PATH environment variable. You have usually different paths when running interactively or as a service. Try to change the path seen by services, or put the ImageMagick executable in the same directory as elogd.
Stefan
| christian wrote: |
|
Update:
While the image scaling via ImageMagick works when running elog manually it doesn't when running elog as a service. The service is hosted in the same user environment that allows image scaling with elog started manually. What else could go wrong?
Christian
|
|
|
|
|
|
68596
|
Fri Apr 7 11:46:09 2017 |
| christian | c_grebing@web.de | Question | Windows | V3.1.0-3c6435e | Re: Elog not see image magick | Ok, this explains why it doesn't work.
Thank you for the support anyway. ELOG is a great piece of software.
Christian
| Stefan Ritt wrote: |
|
Ah sorry. I recall now: Under Windows, calling subprocesses from a service does not work at all. After a couple of days of work I was not able to get this running. If somebody has some idea, I'm happy to try it. So most people use the elogd daemon in the background only under Linux.
Stefan
| Stefan Ritt wrote: |
|
I don't undersand myself fully how services see the environment. Like if they see the PATH at all. In some occations it helped to run the service not under the SYSTEM account, but under the (admin) account of a real user.
Stefan
| christian wrote: |
|
This I do not fully understand: To my understanding the PATH environment variable (includes the ImageMagick path) is a system variable and should be accessable from any account and should be valid under any conditions. Am I wrong? Additionally, I tried adding the system Path variable to the user specific variables for that user that runs the service (Path = %Path%) in the system settings. Finally, I tried copying the imdisplay.exe (ImageMagick executable) and convert.exe (used for the software detection) from the ImageMagick installation directory to the same directory as elogd. Neither of these approaches was successfull.
Christian
| Stefan Ritt wrote: |
|
Must be your PATH environment variable. You have usually different paths when running interactively or as a service. Try to change the path seen by services, or put the ImageMagick executable in the same directory as elogd.
Stefan
| christian wrote: |
|
Update:
While the image scaling via ImageMagick works when running elog manually it doesn't when running elog as a service. The service is hosted in the same user environment that allows image scaling with elog started manually. What else could go wrong?
Christian
|
|
|
|
|
|
|
68139
|
Sun Oct 4 20:29:01 2015 |
 | Jacky Li | zli@hawaii.edu | Question | Linux | V3.1.0-2411f95 | inline jpg to png | Hi,
We have a user who posted a lot of inline jpg. The elog system converted those to png and thus cause the size of the elog to expand about ~4x of the original size. It is caused the problem of entry size too large for email notifications. Is there a way to turn off the conversion to png picture file? May I know also know why it converts to png to store on the server? Thank you very much.
Jacky |
|
68142
|
Tue Oct 13 09:47:18 2015 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | V3.1.0-2411f95 | Re: inline jpg to png | You can turn off thumbnail creation with
Thumbnail size = 0
as written in the documentation. The PNG files are "thumbnails" (= smaller versions of large pictures). Mostly people put large images into elog entries, which take long times to download. Having small thumbnails insted speeds up download times considerably.
Stefan
| Jacky Li wrote: |
|
Hi,
We have a user who posted a lot of inline jpg. The elog system converted those to png and thus cause the size of the elog to expand about ~4x of the original size. It is caused the problem of entry size too large for email notifications. Is there a way to turn off the conversion to png picture file? May I know also know why it converts to png to store on the server? Thank you very much.
Jacky
|
|
|
68213
|
Tue Jan 12 11:35:55 2016 |
 | Johan Forsberg | johan.forsberg@maxlab.lu.se | Request | Linux | V3.1.0-2411f95 | Prefill attributes for new post | Hi all,
I have a use case for ELOG where I need to be able to "prefill" some attributes in the "cmd=new" form, based on the URL.
To illustrate, imagine a link that takes the user directly to the form for creating a new post, with the "Subsystem" attribute already filled out to "Vacuum".
Is this possible already? I've tried naively using URL parameters (e.g. "&Subsystem=Vacuum") but that does not work. If it's not implemented, I think it would be a useful feature to have (and quite important for my particular use case). I could create a new post first using the "elog" tool, with the desired attributes set, but it makes more sense to defer the actual creation of the post to the user, i.e. he/she might change their mind before pressing "submit".
Thanks,
Johan Forsberg, MAX IV Laboratory, Sweden |
|
68214
|
Tue Jan 12 11:48:57 2016 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Request | Linux | V3.1.0-2411f95 | Re: Prefill attributes for new post | Hi Johan,
yes, it is possible. And you were actually very close :-)
In order to pass preset-parameters within a URL, you just need to prefix the fieldname with a "p". In your example, you would write "...&pSubsystems=Vacuum".
Here is an example for the Linux Demo logbook:
https://midas.psi.ch/elogs/Linux+Demo/?cmd=New&pAuthor=Santa+Claus&pSubject=Christmas+Presents&pType=Problem+Fixed&pCategory=Hardware
This feature is even already documented: https://midas.psi.ch/elog/userguide.html#misc :-)
I wish you a Happy New Year!
Andreas
| Johan Forsberg wrote: |
|
Hi all,
I have a use case for ELOG where I need to be able to "prefill" some attributes in the "cmd=new" form, based on the URL.
To illustrate, imagine a link that takes the user directly to the form for creating a new post, with the "Subsystem" attribute already filled out to "Vacuum".
Is this possible already? I've tried naively using URL parameters (e.g. "&Subsystem=Vacuum") but that does not work. If it's not implemented, I think it would be a useful feature to have (and quite important for my particular use case). I could create a new post first using the "elog" tool, with the desired attributes set, but it makes more sense to defer the actual creation of the post to the user, i.e. he/she might change their mind before pressing "submit".
Thanks,
Johan Forsberg, MAX IV Laboratory, Sweden
|
|
|