FSt0p
Enthusiast
FSt0p
Enthusiast
Activity
May 17, 2023
07:29 AM
Until then, no, the message isn't going away. For good reason! For what good reason? Because someone decided that all people are stupid and it's not enough to show some information once? If you don't like the message, upgrade your old, underpowered GPU. ... Now you know how to make it go away. So you are trying to convince me that it's ok to upgrade hardware just to make some bothersome message go away which was intentionally added and has nothing to do with the software functionality? Once again - everything works just fine on the current hardware, just stop bugging me. “If my answers frighten you then you should cease asking scary questions.” ― Quentin Tarantino, Pulp Fiction Your answers doesn't scare anyone, it's not even answer to the question being asked after all. I'm asking maybe there is some registry key or XML config value that can be changed to disable this warning.
... View more
May 17, 2023
07:14 AM
Now look at this from the other side. At the moment ACR works just fine without GPU acceleration, at least for RAW files I'm processing. If the next version (ACR 16 or whatever) will require GPU to edit images - I will not going to upgrade GPU, I will stay on the latest ACR version that works (ACR 15.x). I will see this warning EVERY DAY when I use it, even when changes stated in the warning will already happen. A lot of messages in ACR and LrC can be closed or dismissed completely (with don't show again checkbox), but not this one. And this is annoying.
... View more
May 17, 2023
02:34 AM
1 Upvote
Your answer is as pointless as showing that warning every day. I understand what it says, there is no need to "explain" by just repeating it once again with your own words. And it's more than enough to show it once, but definitely not every day I run ACR. That's a problem! By @TheDigitalDog The real problem is that you are posting in a lot of threads just to post - without providing any valuable answers or additional information.
... View more
May 16, 2023
10:52 AM
1 Upvote
Hi.
When I run ACR 15.3 from Bridge it shows me following message:
"Graphics processor acceleration is currently disabled. Please be aware that Camera Raw will soon require GPU support to edit photos. You can manage GPU settings in the Performance section of the Preferences dialog."
This is not an issue because my GPU is indeed below system requirements - it's fine for me.
I just click ok, message closes and I can work - can close ACR and open once again without this message, can even restart Bridge and open ACR without this message.
But the next day first time I open ACR I get the exact same message once again.
And this happens every day first time I open ACR.
My GPU is unsupported, you showed me the warning - ok, I get it.
But what's the point in showing it every day?
This is super annoying to say the least.
Can this be be disabled?
... View more
Apr 27, 2023
12:46 PM
1 Upvote
Hi. I don't think it's about memory. You are probably just hitting resolution limit, which is 65000 pixels for each side and 512MP at maximum. https://helpx.adobe.com/ua/lightroom-classic/help/supported-file-formats.html Lightroom does not support the following types of files: Adobe Illustrator Nikon scanner NEF Files with dimensions greater than 65,000 pixels per side or larger than 512 megapixels.
... View more
Apr 27, 2023
08:28 AM
2 Upvotes
Hi. Please make AI Denoise collapsible in the Detail panel just like Manual Noise Reduction is.
I get that you want to advertise this new feature, but due to various reasons (processing speed, the fact that it creates separate file) it will not be used on every image by a lot of users.
In my opinion it doesn't even belong to develop panel - having it under Photo>Enhance is more than enough.
But I get that someone may like having it under Details.
So to benefit for both points of view - make it collapsible like you did with the Manual Noise Reduction.
This way it will be there for those who likes this, and will allow to collapse for those who doesn't.
At the moment it just wastes a lot of space in the pannel for this button and description underneath. Thankyou.
... View more
Mar 31, 2023
05:18 AM
@MATTHEW28594348e9jk - calm down a bit. I get your feelings, but this will not help. Let's simplify this a bit. So basically what you are saying has nothing to do with timelapses at all. Your claim is that the same file with the same settings shows different results on different OSs. Could you please post a screenshot of ACR with the DSCF6155.RAF from your archive open with Highlights set to -100 with the file name and settings visible on screen from Windows (should be very dark, almost black) and same screenshot from Mac showing the difference. I guess that would be enough to proove your point.
... View more
Mar 30, 2023
10:40 AM
1 Upvote
Well, that's basically what I've replied in my first message. But @MATTHEW28594348e9jk claims that results with the same files are different on Mac system compared to Windows. I can't test by myself as I don't have access to Mac. Maybe someone else can test on the Mac and post the results here... If indeed behaviour on different OS's differs - this should be a bug.
... View more
Mar 29, 2023
09:42 AM
I missed your point that it's ok on Mac, sorry. Then yes - it should be a bug. Tested on Win 10 22H2 and it's the same behaviour you've showed. Things that I wrote still applies: same development settings will result in different visual appearance if image content changes. For example when the clouds are moving this will lead to changes in the sky brightness if extreme highlight recovery is used, and will lead to flickering. But it's not that extreme brigtness changes as in your case. Also, I've tested before posting - changing ProcessVersion to v2 may be used as a workaround, but in my opinion that's a bad solution to the problem that should not exist on the first place... @Rikk Flohr: Photography - could you please verify this and possibly convert to bug report? For me, it's 100% reproducible on Windows with the provided images.
... View more
Mar 29, 2023
04:30 AM
This is not a bug - it is by design. It may not be intuitive and what you would expect, but it is what it is. In short - tools in Lightroom are content-dependent. What is considered shadows, highlights, blacks and whites depends on actual image - tonal ranges are not fixed. Because of this you get this effect. I can't tell for sure why it acts so differently on visually very similar images thought... For how to deal with this you could watch this video: Stop Lightroom from messing up your timelapses Or you could switch your images to the older Process Version (v1 or v2) - this will also help, but the tools will be different to what you used to.
... View more
Mar 16, 2023
05:08 AM
@Mohit Goyal Thank you for the update. The issue is fixed for me - 13.0.3 Beta works fine.
... View more
Mar 03, 2023
08:33 AM
Thank you for the answer and sorry for bothering. Maybe I don't get how things are working in Adobe internally, but to mee it looks weird that it takes more than a week to just aknowledge issue as a bug or say that it's intended behaviour when it's 100% reproducible. I'm not asking if or when it will be fixed, because I know noone will tell beforehand...
... View more
Mar 02, 2023
04:47 PM
@Rikk Flohr: Photography - could you please tell is there any update on this issue?
... View more
Feb 24, 2023
01:41 AM
@Rikk Flohr: Photography Can you confirm please?
... View more
Feb 23, 2023
03:15 PM
1 Upvote
Hi. Some versions ago "Done" button have been added to export dialog. The intention was to close export dialog and save current export settings without actually running export. Bug is that it only saves builtin LrC export settings. If using export plugin - any plugin settings are not saved when pressing "Done", builtin settings does. If I actually run export - plugin settings are also saved. I see this in LrC 12.2 and some earlier versions on Windows 10 22h2 x64 with various export plugins. Please fix this.
... View more
Feb 22, 2023
02:42 PM
1 Upvote
Hi. Delay is not needed at all - when withWriteAccessDo() returns, data have already been written to the catalog. SDK may be not very clear, but what is really meant there: - callback is the function you wrap with withWriteAccessDo() - if this function makes number of changes, you should not expect that they are written until function returns (in general, there are some exceptions to this listed in SDK) So in short, with your example: withWriteAccessDo("Apply develop settings", function(context) photo:applyDevelopPreset() photo:getDevelopSettings() end) is NOT ok, because it is not guaranteed that develop settings will be written immediately. They are guaranteed to be written when function returns. So it should be like this: withWriteAccessDo("Apply develop settings", function(context) photo:applyDevelopPreset() end) photo:getDevelopSettings() Exceptions that I mentioned is that for example you can create collection and then put photos in that collection inside of the same withWriteAccessDo(), but those are explicitly stated in SDK. Hope this makes things a bit clearer.
... View more
Feb 10, 2023
12:53 PM
1 Upvote
If you'll read my first message carefully, you'll notice that I already knew that because I clearly stated that crash is due to use of SSE4.1 instruction which my CPU doesn't have. What I'm trying to say that this requirement is plain stupid on the first place. Requiring something that improves nothing but just prevents application from running on a certain hardware is not very wise decision. But never mind, I got the attitude.
... View more
Feb 10, 2023
12:00 PM
1 Upvote
Yeh, right. Your explanation is like "it is what it is". You really don't get it? The issue is with one instruction per whole ACR. I can patch it and it will work. How will this affect people with newer CPUs? It will not. If requiring some newer instructions will make application faster - this is understandable. If it's just requirement for the requirement - that's nonsense.
... View more
Feb 10, 2023
11:07 AM
Great! I knew I'll get this answer, but thought why not to try? Adobe is Adobe, nothing changes... And can you clarify why is this? Because of performance? Doesn't look like 14 instructions will be faster than 3, nope. It's just because of someone's very wise decision. Once again - it's only one instruction for the whole binary. Sure it will make huge performance boost... It's just one more example of making very debating (to say the least) desicions and then stubbornly protecting them. Very sad.
... View more
Feb 10, 2023
06:57 AM
I didn't send any crash reports because it just freezes. Crash address and code where it crashes is in the first message. If you need anything else - let me know how to help. Funny thing is that it crashes on this code: 000000004FAF8AE0 66:0F383105 6C558E07 pmovzxbd xmm0,dword ptr ds:[0x573DE055] 000000004FAF8AE9 66:0FEFC9 pxor xmm1,xmm1 000000004FAF8AED 66:0F76C8 pcmpeqd xmm1,xmm0 000000004FAF8AF1 44:0F50C1 movmskps r8d,xmm1 000000004FAF8AF5 45:89C1 mov r9d,r8d 000000004FAF8AF8 41:80E1 02 and r9b,0x2 000000004FAF8AFC 41:D0E9 shr r9b,0x1 r9b=1 if byte1=0 000000004FAF8AFF 45:89C2 mov r10d,r8d 000000004FAF8B02 41:C0EA 02 shr r10b,0x2 r10b=?1b if byte2=0 000000004FAF8B06 44:89C0 mov eax,r8d 000000004FAF8B09 C0E8 03 shr al,0x3 al=1 if byte3=0 000000004FAF8B0C 44:20D0 and al,r10b and byte2=0 000000004FAF8B0F 44:20C8 and al,r9b and byte1=0 000000004FAF8B12 44:20C0 and al,r8b and byte0=0 which is fully equivalent to this one: 000000004FAF8AE0 44:8B05 6E558E07 mov r8d,dword ptr ds:[0x573DE055] 000000004FAF8AE7 45:85C0 test r8d,r8d 000000004FAF8AEA 0F94C0 sete al And if I just patch it in binary - it works fine. And this is the only place where SSE4.1 is required - in fact it's only one CPU instruction. Everything else works just fine.
... View more
Feb 10, 2023
03:40 AM
Hi. I'm experiencing nasty bug with Content Aware Remove in ACR 15.x on older CPUs. In Lightroom Classic ACR (builtin) crashes with "illegal instruction" exception (0xC000001D) due to use of SSE4.2 instruction which my CPU doesn't have. If started from Bridge - ACR crashes with the "illegal instruction" exception (0xC000001D) at the same code, and then with the "stack overflow" exception (0xC00000FD) and Bridge dies. As I can see ACR have different code paths for various CPU features present, at least code pathes for SSE2 and SSE4.2 are present. Everything else apart from Content Aware Remove works just fine. CPU is pretty capable with 6 cores at 4.0 GHz, it's just an AMD CPU and it have SSE3 and SSE4a at maximum, no SSE4.2 Is it possible to make requirement of SSE4.2 optional as it was all the way before release of ACR 15? It's just a matter of one compiler switch after all... I can provide technical details on where exactly ACR crashes if this will help. This all happens under Windows 10 22H2 x64. In ACR 15.1.1 it crashes at RVA=0x28AE0 on code: 000000004FAF8AE0 66:0F383105 6C558E07 pmovzxbd xmm0,dword ptr ds:[0x573DE055] 000000004FAF8AE9 66:0FEFC9 pxor xmm1,xmm1 000000004FAF8AED 66:0F76C8 pcmpeqd xmm1,xmm0 000000004FAF8AF1 44:0F50C1 movmskps r8d,xmm1
... View more
Jan 18, 2023
08:24 AM
Hi. It's me again, maybe I'm just lucky... Here is my test code: local progressTitle = "Exporting..."
local progressScope = LrProgressScope{ title = progressTitle }
local exportSession = LrExportSession{ photosToExport = photos, exportSettings = settings }
local renderOptions =
{
progressScope = progressScope,
renderProgressPortion = progressPortion or 1,
stopIfCanceled = true
}
progressScope:setPortionComplete(0, 1)
LrDialogs.message("ProgressStart="..progressScope:getPortionComplete())
for _, rendition in exportSession:renditions(renderOptions)
local success, pathOrMessage = rendition:waitForRender()
if not success then rendition:uploadFailed(pathOrMessage) end
LrDialogs.message("Progress="..progressScope:getPortionComplete())
end
LrDialogs.message("ProgressEnd="..progressScope:getPortionComplete())
-- set some flag to indicate export cancelation if it's needed
if progressScope:isCanceled() then exportCancel=true end There are two issues with this: 1. progressScope is only updated by the next iterator call, so if there is only one photo to render - it's never updated and stays at 0. If exporting 4 photos - it stays at 0.75 after export, etc 2. progressScope is always reset by exportSession:renditions() - it always starts from 0. What's the point in having the ability to specify partial progress with renderProgressPortion if you can't continue later? Both doesn't look by design to me. Can someone confirm? @johnrellis- maybe you can check? Doesn't seem to be a lot of developers in here...
... View more
Jan 18, 2023
02:12 AM
1 Upvote
Never mind, I've found the solution. exportSession should be bound to progressScope and loop should not be terminated with break before iterator called one more time and will actually see progressScope cancellation and will stop exporting. So this is wrong: local progressTitle = "Exporting..."
local progressScope = LrProgressScope{ title = progressTitle }
local exportSession = LrExportSession{ photosToExport = photos, exportSettings = settings }
for _, rendition in exportSession:renditions{ progressScope=progressScope,stopIfCanceled=true }
local success, pathOrMessage = rendition:waitForRender()
if not success then rendition:uploadFailed(pathOrMessage) end
LrDialogs.message(tostring(success))
if progressScope:isCanceled() then exportCancel=true; break; end
end With this code export will run in background until fully finished despite the fact that progressScope was cancelled because iterator does not actually saw this cancellation. And this will terminate export if it was canceled as expected: local progressTitle = "Exporting..."
local progressScope = LrProgressScope{ title = progressTitle }
local exportSession = LrExportSession{ photosToExport = photos, exportSettings = settings }
for _, rendition in exportSession:renditions{ progressScope=progressScope,stopIfCanceled=true }
local success, pathOrMessage = rendition:waitForRender()
if not success then rendition:uploadFailed(pathOrMessage) end
LrDialogs.message(tostring(success))
end
-- set some flag to indicate export cancelation if it's needed
if progressScope:isCanceled() then exportCancel=true end Hope someone will find this useful one day...
... View more
Jan 17, 2023
03:31 PM
Another related question (or maybe it's the same) - how to stop exportSession:doExportOnNewTask() early? The only workarounds I can think of are: 1. create separate exportSession for every photo - looks stupid and seems to be huge performance degrade 2. call exportSession:removePhoto() or rendition:skipRender() on a running exportSession - maybe it will work, but according to documentation should not. it says they should be called before staring iterator. Neither looks like proper solution to me unfortunately...
... View more
Jan 17, 2023
02:13 PM
Hi. Once again I've faced some strange behaviour with SDK, maybe someone will be able to help. I'm writing export plugin which should extend exporting capabilities. In it's processRenderedPhotos() I get a list of photos selected for export, analyzing them and grouping them into groups. After this each group is exported into different folder. Because I need to perform multiple exports (one for each group) I can't use exportContext. If I try to do so LrC shows error "An internal error has occurred: LrExportContext:startRendering: Can't call twice for the same export context" So I'm using export sessions. Code looks like this: local progressTitle = "Exporting..."
local progressScope = LrProgressScope{ title = progressTitle }
local exportSession = LrExportSession{ photosToExport = photos, exportSettings = settings }
for _, rendition in exportSession:renditions() do
local success, pathOrMessage = rendition:waitForRender()
if not success then rendition:uploadFailed(pathOrMessage) end
LrDialogs.message(tostring(success))
if progressScope:isCanceled() then break end
end It works fine with one huge issue. If user cancells export by pressing X in the progress bar, loop is actually terminated with break, I don't get message boxes with export results, everything looks fine - plugin's function processRenderedPhotos() is terminated. But in fact, all the images from this exportSession are still exporting until they all are exported to the destination. Looks like Lr started exportSession:doExportOnNewTask() and it's running until finishes exporting all photos, or something similar. And I don't see any way to stop this. I tried doing: for _, rendition in exportSession:renditions{ progressScope=progressScope,stopIfCanceled=true } do ... end But it makes no difference. Can this be fixed somehow? Maybe I'm missing something...
... View more
Jan 11, 2023
05:54 PM
Thanks, lack of documentation is not a big issue - I use debugger in such cases 🙂
... View more
Jan 11, 2023
05:52 PM
Thanks a lot, I really appreciate this - it's very helpfull. As for my tests - the issue seems to be with C runtime (CRT). Not sure when it was improved, but my sample code compiled with Visual Sudio 2010 gives wrong results (same as LrC), and exactly same code built with Visual Studio 2019 works correctly. My test code is: #include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <locale.h>
#include <mbstring.h>
wchar_t *MultibyteToWidechar(char *mbstr)
{
wchar_t *wcstr=NULL;
int count=(int)mbstowcs(NULL, mbstr, 0);
if(count<=0) return NULL;
wcstr=malloc((count+1)*sizeof(wchar_t));
if(wcstr)
{
mbstowcs(wcstr, mbstr, count);
wcstr[count]=0;
}
return wcstr;
}
int main(int argc, char *argv[])
{
wchar_t *wcstr=NULL;
char str1[]="ТеСт-TeSt-óó";
char str2[]="тЕсТ-tEsT-óó";
setlocale(LC_ALL, ".UTF8");
wcstr=MultibyteToWidechar(str1);
printf("%S -> ", wcstr);
_wcsupr(wcstr);
printf("%S\n", wcstr);
free(wcstr);
wcstr=MultibyteToWidechar(str2);
printf("%S -> ", wcstr);
_wcsupr(wcstr);
printf("%S\n", wcstr);
free(wcstr);
return 0;
}
... View more
Jan 11, 2023
04:53 PM
One more question - maybe someone can help. Is it possible to write native library (*.dll or *.so) and load it using require() from LrC plugin? I know how it should be done from LUA point of view, the question here is it allowed in Lightroom environment or not?
... View more
Jan 11, 2023
04:24 PM
but on Windows it doesn't convert the case of the Cyrillic letters: By @johnrellis Actually, it doesn't convert anything apart from Latin latters, not only Cyrillic. Don't know if this can be fixed thouth - seems to be system or runtime (CRT) related. I tried to create simple test app in C for case conversion which just calls couple of CRT functions, and behaviour is the same - only Latin letters are converted if I specify UTF8 locale. For CP1251 codepage for example conversion works...
... View more
Jan 11, 2023
01:31 PM
1 Upvote
Hi.
I'm writing Ligtroom plugin, and faced the fact that at least LrStringUtils.upper() and LrStringUtils.lower() doesn't work as expected.
For example for LrStringUtils.upper() documentation says:
Converts a string to uppercase using the operating system's localized case conversion. Unlike the Lua string.upper function, this function properly converts characters outside the 7-bit ASCII space.
In practice: it's not any different from the string.upper() - only characters a-z are properly converted to uppercase.
Here is my test code:
local LrDialogs=import("LrDialogs")
local LrStringUtils=import("LrStringUtils")
local s1=tostring(LrStringUtils.upper("ТеСт-TeSt-óó"))
local s2=tostring(LrStringUtils.upper("тЕсТ-tEsT-óó"))
LrDialogs.message(s1..", "..s2..", "..tostring(s1==s2))
The result is
ТеСт-TEST-óó, тЕсТ-TEST-óó, false
As you can see - only latin characters were converted to uppercase.
Tested under Lightroom Classic v12.1, running on Windows 10 x64 22H2
I can't believe such a thing left unnoticed for so long.
So maybe it's just me missing something...
Can someone test this and confirm?
If this is indeed bug - what's the best way to workaround?
Basically I need to compare file system paths in a case-insensitive manner, and can't find a (working) way to do so without calling external utilities via LrTasks.execute()...
... View more
AdChoices