-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
export-scaled: Update for latest GIMP needed? #8
Comments
I hadn't tried export-scaled in a while, because saver does that plus some other things; but export-scaled is still working for me in 2.8.15. Is it possible that you're trying to save to a file where you don't have write permission, or there's some other problem with writing the file? Can you try running gimp from the command line and see if it prints any error messages? It's also possible there's some Windows-specific problem; I try to do everything in platform-agnostic ways, and I don't think there's any place where I'm stitching together paths with '/' or anything like that, but I don't have Windows to test on so there might be something more subtle going on. |
Thanks - I'll have a look at saver too then - I wasn't sure if that did scaling... Running from command line is tricky, as I'm using GIMPPortable, and the PA launcher just exits immediately after configuring the main app. I did wonder if that might be the problem, but I've just gone back to do some quick tests, and now it appears that export-scaled is working fine! At least, it does save the images. I'll try to recreate the exact conditions and see if the problem has just magically gone away. One other thing I did just notice though - it doesn't remember the previous scale / height / width. Looking at the code, I had thought it would do that. The filename is remembered, but not the export settings... |
It remembers the scale/width/height during a session, but it doesn't try to save those to parasites in the image. Maybe it should (it would only work if the main image was an XCF). If you think it should, please file a separate issue and I'll think about how to do that. |
Just to be clear - I created a new image, scribbled on it, ran Export I'll have a closer look to see if I can reliably reproduce these glitches Tx, David On Tuesday, June 16, 2015, Akkana Peck [email protected] wrote:
|
I've just come back to have another look at this, and now I'm back to the original problem where no image is exported! To reproduce:
After this, I'm left with the original GIMP window, a new image called 'Untitled 2' in the images list, and no exported jpg. If I open a view on the new image, it has been scaled, so it looks like things go wrong on trying to save... I've asked on the PA forum if there is a way to get at the equivalent of the command line output from GIMP, to see if there are error messages. In the mean time, I will experiment with the other plugin you mentioned. Tx, Dave. |
I just tried 'saver.py' using the same recipe as above, and now I do get a jpg exported, but it's at the original resolution not scaled down! Doh! Now, if I could combine the 2... I'm guessing it will be hard to do much without access to the command line output - or is there anything else I can try? |
Honestly, I'm not sure what to try. Both Saver and Export Scaled are properly scaling for me. There's evidently something strange going on with Windows or with GIMP Portable, and I have no way of testing either one. I'm pretty sure running regular GIMP from the commandline is straightforward on Windows (I think you just type the name of the exe, probably after chdir-ing into the right directory). I'm not sure why GIMP portable would be different: do portable apps get executed by some intermediate process that handles the portability part? Here's a discussion of running (regular non-portable) GIMP from the commandline on Windows, in case it helps any: |
Spot on regarding portable apps - they have a 'launcher' executable which sets up the environment, redirects registry stuff, etc. and then finally launches the real app. I'm sure there must be a way to pass on command line parameters or get the console output, and I asked on a PA group, but no reply so far. I'm also away for a few weeks and not able to test any further. But, when I'm back, I'll install regular GIMP and see if the behaviour is any different and post back. Perhaps that will narrow it down to the portable version, and I can then file a bug for that... :| |
Just been looking at this again, and sadly no progress. I removed export-scaled and just left saver in the plugins folder. It too doesn't appear to save the 'session' data. So if I fill in a file name and then enter '25' in the percent box, the numbers all change but the exported file is at 100%. When I re-open the dialogue ('Saver as...'), the filename is remembered but the numbers aren't. Would you be able to try the portable version of GIMP and see if you get anything different? http://portableapps.com/apps/graphics_pictures/gimp_portable |
I can't try portable GIMP, because I don't own a Windows machine, just Linux. It works for me in both GIMP 2.8 and 2.8. I have no idea why it would be different on portable GIMP -- everything is saved in what's called a parasite on the image, and as far as I know those are just held in memory, Did you make any progress on running from the commandline? I could make a version that prints lots of debugging messages, but you can't see them unless you can run from the commandline. |
Still asking on the PA forum about command line output. Also asked other I wonder if parasite data is broken on either Windows or specifically the Tx, David. On Wed, Sep 9, 2015 at 3:02 PM, Akkana Peck [email protected]
|
A friend on the GIMP IRC channel has portable GIMP, and tried it, and says the scale values are being remembered just fine (within the same GIMP session) and the scaled exported image is scaled correctly according to those values. This is with the version at http://portableapps.com/apps/graphics_pictures/gimp_portable, "2.8.14-fix". |
That is the version I was using, but to be sure I just downloaded and installed it to a clean disk, put the 'saver.py' file into the plug-ins folder and gave it a go. I get exactly the same result as before - the exported image was 100%, and the parasite data wasn't saved (but the filename was saved - is that stored somewhere different?). So, I'm stumped. Is your friend using Windows 8.1 Pro 64-bit? I'm wondering if it's an OS thing. I'm going to be installing Windows 10 on another machine later today so will try there too. I also have an old XP machine somewhere - I will try that too and update here. It's very frustrating, but it seems perhaps an isolated case... |
As another data point: I am seeing some of these same issues. Running Windows 7 64bit, GIMP 2.8.14 (non-portable). Using "Export scaled" I don't get any output (I don't see the new "Untitled" image either). I also find that the scaling value isn't retained when I re-enter the Export Scaled dialog. However, for me using the Saver tool does produce correctly scaled exports, and the scale values are retained. Strangely, after using Saver once or twice during a session, "Export scaled" starts working to produce exported files as well. |
I never got a response about how to get the console output from the On Sunday, 13 December 2015, Gordon [email protected] wrote:
|
Weird, now it's working fine, even without running saver. But last night I was definitely seeing the same thing you have been seeing. The scaling value still isn't remembered, of course, but other than that it's working fine now. I'm really not sure what is different now. |
I just came across this - a real time saver. Unfortunately, I'm having problems getting it to work. When I 'Export Scaled...' via the menu, I choose a path and filename, but no files are created. Instead, I see a new 'Untitled' image in the Images list, and I can open a new view and then save it. But that's almost as much effort as before!
I'm using GIMP 2.8.14 (portable, if that makes any difference). Just wondering if perhaps something has changed on the GIMP side that would stop it working...
The text was updated successfully, but these errors were encountered: