I've been working with game textures recently, and doing most of my precision editing in photoshop, and then copying from photoshop and pasting into gimp when they're ready.
I had no trouble doing this with the color textures, I'd paste into gimp, export as .dds and bingo, all good. The game would reproduce the texture on the models just fine.
BUT, when I tried to do the same with the opacity layers, I'd paste into gimp, export as .dds making sure to generate mipmaps, and then all of a sudden the opacity layer was nowhere to be seen. When I edit the game's original opacity layer .dds in gimp itself without pasting from photoshop, the opacity layer is then recognized by the game.
So my question is how do I paste from photoshop into gimp, making sure that I am not bringing any errant data along for the ride that might confuse the way the game renders that layer? Is there something I'm missing?
I've poked around the source code but am having difficulties and am currently trying to figure out how white balance / auto levels is performed.
I think I was able to figure out gimp_operation_levels_map as the root for determining setting gamma but there is a bunch of contextual stuff I am missing.
Example: I'm thinking gimp makes a copy of the xcf representation of the image and performs an update to that. Then there is a history of steps and one can jump back to an intermediate step.
Via bimp, using some of the procedures out of pdb, i noticed that the intermediate steps are not necessarily saved and may be overwritten. For example gimp-drawable-levels (to set gamma) followed by gimp-drawable-levels-stretch wipes out the levels gamma change whereas reverse order works. And ditto for color-levels-gui.
Anyway pointing me to something high level to get around the 15 levels of indirection used in gimp would help.
The city authority cut down some old trees at the back of my house. The trees belong to them, and found to be diseased. A shame to see them go, someone counted the rings and came up with 164 years old.
But it reminded me of this cartoon, About what bears do....
And then export as a jpeg without any soft-proofing.
However the exported jpeg looks different in Krita and Image Magick to GIMP, in Krita and Image Magick the colors are less chromatic, which is what I'd expect.
Anything obvious that might cause this jpeg to look different in GIMP?
I take pictures of different objects on the same background, with the same light source and intensity all the time. I use Gimp to edit those pictures. The camera will vary exposure, aperture, ISO, etc... depending on the object which will change the apparent color of the background.
If I know the actual color of the background (say 90.7, 85.8, 85.8 in a RBG format) how would I apply a filter to color correct the entire image based on the change needed between the current background color and the known background value?
I am looking to try and get the most consistent/accurate colors for the objects. If this is not a good option, please let me know if you think there is a better way to do this. Bear in mind that I am really trying to make up for the camera and getting a better/different camera is not a viabile option at this time.
Out of nowhere Gimp switched to single window mode with fixed panels. So I unchecked the single window box and it reverted to a blank page. When I go to Windows>Dockable Dialogs and click on the Layers Panel, for example, it opens the panel but it jumps to full page spread out in a horizontal format.
How can I restore my set-up to a normal page with movable panels for Layers, Tools, etc.?
I am doing astrophotography and I added the PyAstro for GIMP plugins (https://stargazy.weebly.com/pyastro-for-gimp.html).
These plugins use Python and my system is macOS 11.7.10.
They work perfectly on GIMP v. 2.10.32.
But they don’t work at all on GIMP v. 2.10.34.
The error is located in the scripts at : from gimpfu import *
Is the gimpfu file missing in GIMP v. 2.10.34 ?
I wrote a python script that removes a background colour from an image, orientates the remainder, resizes the image and then overwrites the existing image file. All of the functions work as expected...but they don't happen in the order expected. The final two lines (below) happen in reverse order.
I doubt very much that the above cobbled together solution is optimal so I'll take pointers but I'm also curious as to why it doesn't work sequentially? I thought that was the whole point.
