ktgw0316 / LightZone

LightZone is a photo editor for Mac, Windows, and Linux.
BSD 3-Clause "New" or "Revised" License
324 stars 50 forks source link

Editing tools too small to use #307

Open OldNick opened 1 year ago

OldNick commented 1 year ago

I have a high definition monitor (3840 X 2160) with opensuse KDE.

The editing tools, sliders, and text are simply too small to use. The colour balance tool is a tiny disk about 1.5cm in diameter and impossible to use with any accuracy.

How do I configure it to be able to see the tools? (Not to mention the help file)

It's a pity, the app seems to be capable of giving good results.

OldNick commented 1 year ago

To be more precise about the issue. It makes me think about certain Gnome apps which don't always play nicely on KDE - size and visibility of parts of the UI being the problem. Gnome disk utility is a case in point - icons and text microscopic. Certain KDE themes have support for Gnome styling, but even so they manage to ignore it.

So, in Lightzone, the Menu bar, the top of the window and the left sidebar are normal (the same as other apps). It is the right sidebar where there is a problem : the content of each tool container should double in size.

If there is a configuration override I could put in home/.java, I'd be willing to try, but someone would have to tell me what and where...

Later... I tried the interim solution proposed in issue #284 but it comes out too big - then tried scale=1.5, but it was ignored - seems to only like whole numbers

ktgw0316 commented 1 year ago

@OldNick Would you post a screen shot?

Is it specific to KDE? I guess that it is a bug related to Java Swing, so it will occur on other Linux desktop environment.

OldNick commented 1 year ago

@ktgw0316 I'll try to organize the screenshot I've been doing a bit of research (I'm learning more than I want or need about java!) I'm now not surprised that the problem reminds me of other Gnome apps - java GUI's use gnome settings for text size. So the problem would seem to be exposing the tool containers to the font scaling of the rest of app's GUI.

I've just managed to install LightZone on my Chromebook (another learning curve!) - as at the moment it doesn't support the G90 but does the GX9 it's a good idea - the GX9 is what I use when traveling and the Chromebook goes with me - so I'll see how it does there. It needs scaling there too but there Chrome linux is Debian / Gnome, so it may be different.

OldNick commented 1 year ago

Haven't organised the screen shot yet, but wanted to report on the chrome linux installation - It works, but the scaling problem is there also - a 13 inch screen 2250 X 1504 pixels! Everything is very small, because whereas Chrome OS offers scaling options to get things readable, Chrome linux... not so much, and while I can get gnome to scale it doesn't get through to LZ.

Anyway it is usable, albeit not as comfortably as it could be.

More important is getting libraw and camera support sorted out.

OldNick commented 1 year ago

Here is a screen shot of part of the right sidebar Screenshot_20230912_145309-1

As I said above, my KDE theme makes Gnome styling follow the system - so all the orange title bars have gone and some of the text has followed the system. But not in the tools.

My monitor is 27inch and the screen shot represents an area approx 23 X 9 cm (here it's about 1.5 times what it looks like on my screen). On the screen the zonemapper is roughly 4 X 3cm and the diameter of the colour wheel 1.8cm.

When I tried the solution of scaling up (#284) I got the feeling that the zonemapper didn't know quite where it was - I suspect it and the colour wheel need their own scaling algorithm so they work properly.

The problem with linux is that not everyone uses Gnome (I'm in KDE) and Gnome is not the easiest to configure - pretty unfriendly, in fact). Added to which, Linux itself, has not not addressed the question of large monitors - once you get over a certain size, you have to accept a smaller, default, option and then they propose a scaling factor so you can see it. I have no idea what Windows does - haven't been near it in years. Although I would think in the Java community there must be various solutions in use.

Rawtherapee has a checkbox for what they call "pseudo highDPI mode" which enlarges parts of the GUI (mostly icons)

sfink16 commented 1 year ago

@OldNick Your screenshot looks to be good size on my small monitor (1900X1280). I do see "Fractional scaling" in my Ubuntu 22.04 OS. I tested it and it works in increments of 25% (IE, 100%, 125%, 150%, etc.). Perhaps this link might help explain it better then I can: Fractional Scaling I have no idea if this helps or not.

OldNick commented 1 year ago

I changed the image in my comment above - the original was 100ppi rather than the standard convention of 72ppi - I thought there might be a discrepancy between image size and the reality which is why I specified the dimensions in the comment. If the tools were at the size they appeared in the original image, I wouldn't be complaining!

Theoretically everything is scaled on my monitor at 125% - except Gnome apps and by extension Java and... Firefox, which has it's own scaling which they call "zoom". As I said, my theme in KDE has a little plugin that can interact with Gnome, but only those bits which are exposed to the plugin.

As I said, I tried the solution of scaling up in user/bin - 200% worked, but was way too big (and zonemapping seemed to be having problems), I then tried 150% and it changed nothing (maybe I made a mistake - always possible - but I don't think so)

Ubuntu, I think, is built on the back of Gnome, so you shouldn't be having any problems, whatever you do.

I don't know how all the other "flavours" and distributions of Linux behave - but it's a secondary problem compared to getting the app up to speed with camera support and the like.

The more I use it, the more I like it, although, paradoxically, I'm happier dealing with curves than zones.

sfink16 commented 1 year ago

@OldNick I'm still seeing the problem that you are seeing, but am not denying that you see the problem.

That said, your comment of getting the "app up to speed with camera support" is moving along, see THIS LINK for more information. That link also refers back to the other "Issues" that started the upgrade work. Please remember that we only have one developer, who resides on the other side of the world, who has a job during the week, and English is not his first language.

Also, I think it was you that mentioned Showfoto, if it was you thanks! The "Import Raw Using Libraw" is very helpful in how Libraw can be used and helpful. I used for research to try to match how it help the LZ development.

Steve

kunibertk commented 1 year ago

I observe the same issue as @OldNick. I am using ArchLinux with KDE on a 32" 3840x2160 screen. KDE overall application scaling is set to 150%. I have updated to 5.0.0beta2 (from beta1) this morning and the result is the same. I am using java-21-openjdk by default but the result is the same with java-11-openjdk, java-17-openjdk or liberica-jre-11-full. Lightzone does not work at all with java-8-openjdk (as expected).

Most lightzone GUI elements have an appropriate scale, for example the file selector, the menu, the edit icons and the metadata editor (which in the browse screen has the location that the editing tools have in the edit screen). However the editor tools, and the file names underneath the images in the browse screen, are too small (I don't care about the file names though but it might give a hint what they have in common).

When I use -Dsun.java2d.uiScale=2, the editing tools are slightly too large, but the other GUI elements are now grotesquely enlarged. However this would be workable if there were not another issue which I opened as #325.

I haven't used lightzone for almost a year. Previously, lightzone had a reasonable overall scale with -Dsun.java2d.uiScale=2 without the tiling effect. I will try to downgrade to the version that was recent about a year ago and see if I can work with that.

Here the edit window as a whole (scaled 50% for image size) so you can see the difference in size between the various GUI elements:

lzbug - tools view s
kunibertk commented 1 year ago

Not sure if that points to a solution but there appear to be a few hard coded sizes in lightcrafts/src/com/lightcrafts/ui/operation/SelectableTitle.java. Also, the controls in the tool title bar are not controls from any GUI framework, but they are PNG images size 15x15.

When I modify, for example, files check.png, check_H.png, uncheck.png, uncheck_H.png in lightcrafts/resources/com/lightcrafts/ui/operation/resources/, to have sizes 22x22 instead, the GUI becomes much more usable (for my screen size and my screen size only). My gut feeling is that a checkbox should come from a GUI framework and not be hardcoded with PNG files though.

OldNick commented 1 year ago

@kunibertk Therein lies part of the problem - as you suggest each tool should, if possible be a form which should propose a check-box as one of the controls. What worries me the most, however is the size of the Tonemapper and Color Balance controls

kunibertk commented 1 year ago

I had a quick look at ColorWheel.java and it defines the color wheel to be 100x100 pixels large. This matches the display on my screen. So, this appears to be hard coded. Not sure why the Gnome users don't have the same effect; maybe fractional scaling in GTK vs Qt handle hard coded sizes differently.

But I did notice that a lot of the lightzone 5 GUI listens to the desktop's overall scaling, while in previous lightzone versions 4.x, all menu items and GUI controls were too small.

sfink16 commented 1 year ago

@kunibertk Therein lies part of the problem - as you suggest each tool should, if possible be a form which should propose a check-box as one of the controls. What worries me the most, however is the size of the Tonemapper and Color Balance controls

Tonemapper is useless for me out of the box settings. I get two vertical lines running through the image. I have to reduce the Detail slider all the way to the left to eliminate the lines. There used to be an open issue for the Tonemapper lines, but I can't find it now.

kunibertk commented 1 year ago

@OldNick for me the following work-around helps: In KDE settings, Workspace Behaviour > Desktop Effects > Accessibility, there is a Magnifier tool that allows to magnify the region around the cursor. Default is 200x200 pixels but I have set it to 1000x200 pixels so that I can see the full width of a lightzone editor control. I can then switch it on and off with the configured hotkeys. This helps me to hit the controls I want to hit (and not the ones next to them).

washere commented 2 months ago

For me too, the interface UI elements are just too tiny to use. Shame as it is a great work, but unusable. I tried various hacks/codes but not good. There are global hacks but I do not want make everything else oversized as a result, so global sys zoom-in is no solution as some might suggest unwisely.

Other RAW file image editors like RawTherapee & DarkTable etc do not have this problem & I use them now. ShowFoto has a small interface UI elements but it is just usable & my third choice. Shame, as LightZone would have been great.

I'm on LMDE (Debian) with Cinnamon. Thanks anyway.