Neue Testversion 18.40b17

Hier diskutieren die Betatester von PhotoLine untereinander und mit den Entwicklern
bkh
Betatester
Beiträge: 3674
Registriert: Do 26 Nov 2009 22:59

Re: Clear the Recent Files list

Beitrag von bkh »

Martin Huber hat geschrieben:
bkh hat geschrieben:Indeed! – maybe "Clear Menu" would be a bit less ambiguous – maybe also add a separator line between file names and "Clear" command, to make the entry more visible (most Mac programs do it that way).
On Mac OS the Recent Files are a submenu. And at least here on my Mac there is a separator between the filenames and the Clear command.
Sorry, the missing separator line seems to be due to my custom menu settings (MenuStructure.txt). If I use the standard setup, it's there. (Is there a menu entry code for the "Delete (Clear Menu)" menu entry? :mrgreen: )

Cheers

Burkhard.
Martin Huber
Entwickler
Entwickler
Beiträge: 4161
Registriert: Di 19 Nov 2002 15:49

Re: Clear the Recent Files list

Beitrag von Martin Huber »

bkh hat geschrieben:Sorry, the missing separator line seems to be due to my custom menu settings (MenuStructure.txt). If I use the standard setup, it's there. (Is there a menu entry code for the "Delete (Clear Menu)" menu entry? :mrgreen: )
There isn't one. But it wouldn't work well with a MenuStructure.txt anyway, because after applying the Clear command, the separator will be deleted. And with a MenuStructure.txt it won't be recreated afterwards.

By the way: Where did you place your MenuStructure.txt? Modifying the PhotoLine.app-bundle should no longer be allowed (due to Apple's new code signing rules).

Martin
bkh
Betatester
Beiträge: 3674
Registriert: Do 26 Nov 2009 22:59

Re: Clear the Recent Files list

Beitrag von bkh »

Martin Huber hat geschrieben:By the way: Where did you place your MenuStructure.txt? Modifying the PhotoLine.app-bundle should no longer be allowed (due to Apple's new code signing rules).
Apple's code signing isn't very clever – you only have to start PL once with its original file, and after that, you can still mess with the resources.
Therefore, I just launch and quit PL once and then replace the MenuStructure.txt file in the Resources folder, as usual.

Cheers

Burkhard.
Benutzeravatar
photoken
Mitglied
Beiträge: 2162
Registriert: Sa 28 Sep 2013 01:25

Re: Clear the Recent Files list

Beitrag von photoken »

Martin Huber hat geschrieben:On Windows the Recent Files are a part of the File menu, so a separator between the filenames and the Clear command might make the situation ambiguous.
I completely agree. However, using "Clear list" instead of "Delete" would be better -- "Delete" has certain dire connotations and "Clear list" would be less ambiguous and less intimidating for new users.
Ken
Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.
Benutzeravatar
Hoogo
Betatester
Beiträge: 4021
Registriert: So 03 Jul 2005 13:35
Wohnort: Mülheim/Ruhr

Re: Neue Testversion 18.40b17

Beitrag von Hoogo »

15:8:2014:21:43:41: Sharpen hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:43:58: Arrange hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16

Der obere Eintrag bezieht sich auf den Zustand nach dem Öffnen von PL,
der Untere auf ein eingefügtes Bild aus der Zwischenablage.

Das hier kommt dann bei jedem Neuzeichnen des Menüs, ich hab hier immer zu einem anderen Hauptmenüpunkt rübergewackelt:
15:8:2014:21:46:42: Arrange hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:46:51: Arrange hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:46:53: Arrange hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:47:17: Arrange hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:47:19: Arrange hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:47:20: Arrange hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:47:20: Arrange hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:47:21: Arrange hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:47:21: Arrange hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:47:21: Arrange hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:47:22: Arrange hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:47:22: Arrange hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:47:24: Arrange hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16

Und nach dem Schliessen des Bildes ist das Menü wieder das erste:
15:8:2014:21:51:49: Sharpen hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:51:51: Sharpen hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:51:52: Sharpen hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:51:55: Sharpen hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:51:56: Sharpen hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:51:56: Sharpen hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:51:57: Sharpen hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:51:57: Sharpen hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:51:57: Sharpen hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:51:58: Sharpen hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
15:8:2014:21:51:58: Sharpen hat falsche Hoehe in DrawItem: Soll: 22 Ist: 16
----------------
Herr Doktor, ich bin mir ganz sicher, ich habe Atom! /Doctor, doctor, I'm sure, I've got atoms!
Benutzeravatar
Herbert123
Mitglied
Beiträge: 2140
Registriert: Sa 12 Mai 2012 21:38

Re: Neue Testversion 18.40b17

Beitrag von Herbert123 »

Photoline no longer refreshes the display when:
- I use the color filter on a grey scale bitmap layer
- and add a layer effect (color overlay) and an adjustment layer
- next I try to turn off the color filter in the layer properties.

Nothing happens. When I switch to a different colour mode (kind) it does refresh the view.

Attempting to change the color filter parameters also stops working.

Btw, the word "Kind" is incorrect use in English: it should either be "image mode" or "(image) type".
/*---------------------------------------------*/
System: Win10 64bit - i7 920@3.6Ghz, p6t Deluxe v1, 48gb (6x8gb RipjawsX), Nvidia GTX1080 8GB, Revodrive X2 240gb, e-mu 1820, 2XSamsung SA850 (2560*1440) and 1XHP2408H 1920*1200 portrait
Benutzeravatar
photoken
Mitglied
Beiträge: 2162
Registriert: Sa 28 Sep 2013 01:25

Bug: Incorrect bit depth displayed for floating-point DNG

Beitrag von photoken »

Win7 x64 SP1
PL 18.40b17 x64

When I open an HDR floating-point DNG image created with HDRMerge (0.4.5), the title bar in PL describes the image as a "16-bit RGB" image, regardless if the DNG image is a 16-bit, 24-bit or 32-bit image.

Added:
Using EXIFTool GUI, I found the only consistent place in those DNGs containing the EXIF data is this one:
EXIF bpp data.png
Added:
When I look at the Layer Properties of the image layer of 24-bit or 32-bit floating-point HDR DNG images, both show as "16-bit". If this means that I must manually change the layer "kind" to 32-bit, it's not good -- the bit depth should be automatically set according to the opened image.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Ken
Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.
Benutzeravatar
Gerhard Huber
Entwickler
Entwickler
Beiträge: 4143
Registriert: Mo 18 Nov 2002 15:30
Wohnort: Bad Gögging

Re: Bug: Incorrect bit depth displayed for floating-point DN

Beitrag von Gerhard Huber »

photoken hat geschrieben:When I open an HDR floating-point DNG image created with HDRMerge (0.4.5), the title bar in PL describes the image as a "16-bit RGB" image, regardless if the DNG image is a 16-bit, 24-bit or 32-bit image.
HDRMerge creates uninterpolated float DNG files. They have float values of 16, 24 or 32 bit per Pixel. PhotoLine loads this DNG files with dcraw. When it is loaded, it has to be demosaiced. We have no code in PhotoLine that can demosaic float images, so the image is reduced to 16 bit integer, then demosaiced and after this opened in PhotoLine.
If there was more then 16 bit information in the image, it is lost this way. The only way to solve this would be, that HDRMerge would save the images in a more commen file format like TIFF.

Gerhard
Benutzeravatar
photoken
Mitglied
Beiträge: 2162
Registriert: Sa 28 Sep 2013 01:25

Re: Bug: Incorrect bit depth displayed for floating-point DN

Beitrag von photoken »

Gerhard Huber hat geschrieben:HDRMerge creates uninterpolated float DNG files. They have float values of 16, 24 or 32 bit per Pixel. PhotoLine loads this DNG files with dcraw. When it is loaded, it has to be demosaiced. We have no code in PhotoLine that can demosaic float images, so the image is reduced to 16 bit integer, then demosaiced and after this opened in PhotoLine.
If there was more then 16 bit information in the image, it is lost this way. The only way to solve this would be, that HDRMerge would save the images in a more commen file format like TIFF.
Ah, I understand. Thanks for the explanation. I will probably never need to use the 24-bit or 32-bit options in HDRMerge, but I'll remember this if I ever need to use those higher bit depths. In those cases, I'll do the RAW processing exclusively in RawTherapee and export as 16-bit TIF. When I have a 16-bit HDRMerge image, then it sounds like I have the option of processing the image in either RT or PL.
Ken
Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.
Benutzeravatar
Hoogo
Betatester
Beiträge: 4021
Registriert: So 03 Jul 2005 13:35
Wohnort: Mülheim/Ruhr

Re: Bug: Incorrect bit depth displayed for floating-point DN

Beitrag von Hoogo »

Gerhard Huber hat geschrieben:...this DNG files with dcraw...
What if the coder of dcraw is informed about these Dngs and makes an update?
----------------
Herr Doktor, ich bin mir ganz sicher, ich habe Atom! /Doctor, doctor, I'm sure, I've got atoms!
Benutzeravatar
photoken
Mitglied
Beiträge: 2162
Registriert: Sa 28 Sep 2013 01:25

Re: Bug: Incorrect bit depth displayed for floating-point DN

Beitrag von photoken »

Hoogo hat geschrieben:What if the coder of dcraw is informed about these Dngs and makes an update?
I'm not sure that it's dcraw that is the problem. As I understand it, the demosaicing is done by the DCB, or AHD, or VNG libraries. I'm beginning to understand why RawTherapee needed the developer of HDRMerge to supply the code to enable RT to process those HDR DNGs....
Ken
Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.
Benutzeravatar
photoken
Mitglied
Beiträge: 2162
Registriert: Sa 28 Sep 2013 01:25

Re: Bug: Incorrect bit depth displayed for floating-point DN

Beitrag von photoken »

Gerhard Huber hat geschrieben:...If there was more then 16 bit information in the image, it is lost this way.
An additional thought about this: Since PL is reducing the image to a 16-bit integer precision, it seems only right to alert the user to this fact and that some image information will be lost. A message box with this warning (and an option to disable future displays of the warning) would suffice.
Ken
Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.
Benutzeravatar
photoken
Mitglied
Beiträge: 2162
Registriert: Sa 28 Sep 2013 01:25

only 16 bit depth displayed for floating-point DNG

Beitrag von photoken »

Gerhard Huber hat geschrieben:
photoken hat geschrieben:When I open an HDR floating-point DNG image created with HDRMerge (0.4.5), the title bar in PL describes the image as a "16-bit RGB" image, regardless if the DNG image is a 16-bit, 24-bit or 32-bit image.
HDRMerge creates uninterpolated float DNG files. They have float values of 16, 24 or 32 bit per Pixel. PhotoLine loads this DNG files with dcraw. When it is loaded, it has to be demosaiced. We have no code in PhotoLine that can demosaic float images, so the image is reduced to 16 bit integer, then demosaiced and after this opened in PhotoLine.
If there was more then 16 bit information in the image, it is lost this way. The only way to solve this would be, that HDRMerge would save the images in a more commen file format like TIFF.
Has any progress been made with editing floating-point DNG images in PL? Is the limitation in PL, or in DCRAW, or in the demosaicing algorithm (DCB, in my case)?
Ken
Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.
Benutzeravatar
Gerhard Huber
Entwickler
Entwickler
Beiträge: 4143
Registriert: Mo 18 Nov 2002 15:30
Wohnort: Bad Gögging

Re: only 16 bit depth displayed for floating-point DNG

Beitrag von Gerhard Huber »

photoken hat geschrieben:Has any progress been made with editing floating-point DNG images in PL? Is the limitation in PL, or in DCRAW, or in the demosaicing algorithm (DCB, in my case)?
No, until your tool won't create a better file format, for example TIFF or PSD this won't be changed. We have no demosaic function for float images here.

Gerhard
Benutzeravatar
photoken
Mitglied
Beiträge: 2162
Registriert: Sa 28 Sep 2013 01:25

Re: only 16 bit depth displayed for floating-point DNG

Beitrag von photoken »

Gerhard Huber hat geschrieben: No, until your tool won't create a better file format, for example TIFF or PSD this won't be changed. We have no demosaic function for float images here.
Just so I'm sure I understand: if DCRAW (and DCB) were able to demosaic the floating-point DNG images, then PL would be able to edit the images as 32-bit floating-point images?
Ken
Yes, I think it can be eeeeeasily done....
Just take everything out on Highway 61.