| Welcome, Guest |
You have to register before you can post on our site.
|
|
|
| Darktable Images Opening In Task Bar At Bottom Of Screen |
|
Posted by: NorthernHarrier - 05-03-2024, 02:13 AM - Forum: Windows
- Replies (5)
|
 |
I just installed a new Windows 11 Dell desktop computer and re-installed GIMP (version 2.10.36) and darktable (version 4.6.1). I spent a long time figuring out how to get photo thumbnails to show up at the top of the screen again when I open photos in GIMP, as they did with my old computer. However, the problem I cannot solve is this: when I open a raw image through GIMP from my photo files stored on my computer drive, the image loads first in darktable as it should, but the darktable window with the image appears at the bottom of my screen, in the task bar, in a tiny thumbnail. In order to close it, so it will re-open in GIMP for editing, I have to hover my mouse over the tiny image and click on it to get it to move into the main GIMP layout in larger form. The images are not opening in darktable in larger form on the main GIMP layout as they always did with my old computer. I tried uninstalling and re-installing darktable, but that didn't help.
The attached image shows where the tiny thumbnail of the photo opens in darktable when I open a raw image in GIMP from my camera. I've circled the tiny thumbnail of the darktable window that opens at the bottom of my screen when I open a raw image in GIMP.
How can I get the images to open in the darktable window within the main GIMP layout, so I can close them and they will re-appear in GIMP for editing as they should? I can't find any menu item in GIMP or any preference item in darktable that will solve this issue. Any help you can provide will be greatly appreciated - there is no other online help addressing this issue that I can find. Thanks!
|
|
|
| Getting active image and layer in Python scripts |
|
Posted by: Ofnuts - 05-02-2024, 07:32 AM - Forum: Tutorials and tips
- No Replies
|
 |
If your script is correctly written, in particular its "registration" code, it gets the active image (and the active layer) as parameters:
Code:
#!/usr/bin/python
# -*- coding: UTF-8 -*-
from gimpfu import *
def theCode(theImage,theDrawable):
pdb.gimp_message('Running on image "%s" (%d) on drawable "%s"' \
% (theImage.name,theImage.ID,theDrawable.name))
register(
'the_registration_atom',
'Example registration of a python plugin (short description, pops up in menus)',
'Example registration of a python plugin (long-winded help that shows in the PDB browser)',
'Author','Copyright owner','2021',
'Test menu item',
'*', # works on all image types
[
(PF_IMAGE, "image", "Input image", None), # Active image if called from the UI
(PF_DRAWABLE, "drawable", "Input drawable", None), # Active drawable if called from the UI
# Other parameters would come here
],
[
# if you want to be really nice and your script creates image/layers, you can return
# then and descrive their type here. Makes it easier for other scripts calling your script.
],
theCode,
menu='<Image>/Test/',
)
main()
Notes:
- An important part is the use of the menu named argument. This makes the registration use the new variant. The older variant where the 7th argument is a full path to the menu item (which is still found in some examples) behaves a bit differently.
- The "drawable" can be a layer (usual case) but also a layer mask or a channel or even a layer group. Some scripts can work on all types, others may want just a layer. You can use a PF_LAYER instead of a PF_DRAWABLE but the Gimp error message isn't too user-friendly. Better check in your code and react appropriately.
- Since the script works on a drawable, the menu item is disabled if there is no active drawable in the image (this can happen after you deleted all layers). You can of course remove the drawable argument if the script doesn't require a specific drawable (runs on all layers, or generates new ones)
- Since the script works on an image, the menu item is disabled if there is no image in Gimp. You can of course remove the image argument if the script doesn't require a specific image (runs on all images, or loads/generates new ones)
An example script "core" with long-winded comments:
regdemo.zip (Size: 2.2 KB / Downloads: 413)
|
|
|
|
| python-fu pdb.file_exr_save issue |
|
Posted by: JBreckeen - 05-01-2024, 03:12 PM - Forum: Scripting questions
- No Replies
|
|
Hello again, so I have maybe an odd one.
Does anybody know if there are issues with .png's saved with the python pdb.file_png_save()? In my plugin, any image I "save" using that has issues opening on some viewers, while the same image exported through Gimp's UI using the same settings works perfectly fine.
As a test, I have a simple white image. If I export it as a .png (16b RGBA) through the UI, works fine everywhere. But same .xcf saved with this code
Code:
def savePNG(image=None,
drawable=None,
filePath=None,
interlace=0,
compression=5,
bkgd=1,
gama=0,
offs=0,
phys=0,
time=0,
comment=0,
svtrans=1
):
try:
pdb.file_png_save2(image,
drawable,
filePath,
filePath,
interlace,
compression,
bkgd,
gama,
offs,
phys,
time,
comment,
svtrans)
return True
except Exception as e:
log.warning("ERROR: ", e)
return False
has the issue. Keep in mind all the variables get their values set from outside, and it does not seem to matter what options are selected - it always has the problem.
The "bad" .png works in: Gimp, Photoshop, Blender, Maya, OpenRV, win10 Photos, Paint, Darktable - and probably plenty of otherss.
But it does NOT work in DJV, or ColorSync viewers (and maybe others). Which of course is what we normally use and need.
When I have looked at the image details in RV, both files appear the same.
BTW I also tried pdb.file_png_save() as well
So, has anybody seen differences?
Thanks much,
J.
AH!!!!! Nevermind to all of that. I found the issue:
I stupidly overlooked the bool vs binary problem: True/False vs 0/1.
Doh!
Sorry for the interruption.
J.
|
|
|
|
| Currently Active Image |
|
Posted by: JBreckeen - 05-01-2024, 02:54 PM - Forum: Scripting questions
- Replies (6)
|
|
Hello all.
So I have searched and found some info saying this may not be able to be done, but I would really like a way to infer the currently-viewed image in python-fu.
I need this since I have a plugin (think of it more as an extension in other software), that communicates with Gimp from outside. Mostly is handles loading, saving, and exporting of image files to our pipeline. Right now I just use:
currentImage = gimp.image_list()[0]
currentDrawable = pdb.gimp_image_get_active_layer(currentImage)
which works if there is either one image file open, or want to deal with the last opened. But would really prefer to be able to have it work on whatever image is "active". I have read there is nothing in the API that deals with the active, but are there any work-arounds?
Is there something that I am missing?
Thanks in advance,
J.
|
|
|
|
| creases |
|
Posted by: novalore40 - 04-27-2024, 12:35 AM - Forum: General questions
- Replies (13)
|
|
I have always used an older version of gimp like 2.8 or something like that i just upgraded to 2.10.36. now this is my problem i make clothes for sims and i always used the bump map when doing this in 2.8...I did this by adding a new transparent layer putting the creases in white on that layer and then go to where i want the creases to be on the main colored layer and opening up bump map and clicking on the crease layer so it would bump map it to the colored layer. pretty easy and straight forward now my problem is i go to do that in the new gimp and i get nada nothing ect, i have looked for tutorials that explain how to do this but find none. can anyone help ty in advance
|
|
|
|
|
