Corel bought out Bibble

[bakubo]

What we really need is a challenge of a different type - I guess I'll have to put one up - where we get people to donate some good and some blown but recoverable RAWs and let everyone PP them in their own way, documenting what they used and the methodology to get a good/fantastic print.

That would be cool. I guess agorabasta or David should easily walk away the winner, but we could all give it a try.

[David Kilpatrick]

As you say Henry - mainly because we have both collected loads of raw conversion programs, and they all have their own ways of recovering highlights, so you could just use different ones until the best was found. But, with most cameras, ACR/LR has been as good as you normally need for some time.

David

[agorabasta]

I'd say even more - right now the very best option for highlight recovery is the Lr4 beta. So there's hardly any contest possible, as that beta is a publicly available free download

[pakodominguez]

I was disappointed when Adobe released LR 4 Beta that it only works on Vista and later OS. My main photo processing systems are both XP, and I'm not ready to upgrade and reinstall all my software/hardware or buy a 3rd desktop system...

Tom,
I believe that LR4 works on XP, the problem is that Adobe do not support "customer service" for XP. As far as your LR4 runs OK, you don't need to upgrade to WIN7. Just give it a try.

Today I tried to install LR4 at work and it doesn't allowed me to do so because XP... so "no support" didn't mean customer service but "non compatible"

[agorabasta]

Pako,

The memory management is very different in XP and Vista/7. So a memory-hungry prog like Lr needs two separate routines to support both types. So they just saved a little bit on development, and maybe earned some speed too by simply ditching the XP support altogether.

Quite interestingly though, the XP memory architecture after the SP2 is often faster and always more fool-proof than that of the 7... But most of the extant copies of XP are only 32-bit, while we really need a 64-bit OS to run Lr efficiently enough.

[jcoffin]

Pardon my asking, but what are you talking about? From the looks of things, they do their memory management with the standard library functions (malloc, free, etc.) that have remained unchanged for decades. Given the amount of C++ involved, quite a bit of it probably goes through new and delete (and/or Allocator objects), but I'd have to do a bit more work to verify that.

Doing a bit of looking with dependency walker, it appears that the real problem (or at least one real problem) is a bit of optimization in threading -- they're using Slim reader/writer locks, which were new in Vista (AcquireSRWLockExclusive, AcquireSRWLockShared, InitializeSRWLock, etc.) For what it's worth, it looks like they do still use critical sections as well (they use InitializeCriticalSection, EnterCriticalSection, LeaveCriticalSection, etc.)

If you want to discuss it further, it's probably best to move the discussion to someplace that programming questions are at least reasonably topical (e.g., StackOverflow.com).

[agorabasta]

Pardon my asking, but what are you talking about? From the looks of things, they do their memory management with the standard library functions (malloc, free, etc.) that have remained unchanged for decades.

I'm certainly not a SW developer, my last attempt at writing some x86 assembly code was about 25 years ago But I definitely do have some understanding of the basics.

Anyway, here's some discussion on the XP/7 differences and how that may be related to Lr4 (the messages in the thread by the same author deserve reading) - http://forums.dpreview.com/forums/read. ... e=40287899

[bfitzgerald]

I think this is a bad move for Bibble. Among PC folks Corel and not well liked and they pretty much stuffed up paint shop pro (which had a lot of potential) loading it with DRM measure, making it bloated and slow and basically ruining the software. They also consumed other software such as InterVideo and same results on that one. WordPerfect again once a leader in the market acquired by Corel and essentially irrelevant to the market place (you either use MS office of Libreoffice)

Bibble will likely suffer the same fate. I don't blame the developers they probably got a nice cheque and a Lamborghini But among PC enthusiasts Corel are known as
"Where good software goes to die"

[twm47099]

I think this is a bad move for Bibble. Among PC folks Corel and not well liked and they pretty much stuffed up paint shop pro (which had a lot of potential) loading it with DRM measure, making it bloated and slow and basically ruining the software.

I've used PSP since version 7 (Jasc). No doubt Corel put their mark on the product, and some uses weren't happy with what they did. But while some things were negative, they did finally add features that users had been calling for, such as 16 bit color. When first added, there were very few tools that would work on 16 bit. Each new version has increased the number of features that can work with 16 bit. They also finally got color management to work right around version X2 (the latest version I have). It is not the fastest program, and it has its limitations (raw conversion is one). But for photographic applications it's reasonably close to Photoshop and a heck of a lot less expensive.

I'm interested in ASP and in seeing if Corel enhances the connection between ASP and PSP. I would not be happy if they combined them (too big and I would expect too sloooow.) I would also not be happy if they decided to discontinue PSP or turn it into primarily a video editor.

tom

[jcoffin]

Agorabasta: What he's claiming strikes me as about as relevant as the price of tea in China, as the old saying went. "Keith Z Leonard" strikes as mostly blowing smoke. What he's trying to blame is irrelevant, and a fair amount of the rest is just plain nonsense.

In any case, it took me only about 5 minutes to do what he doesn't seem to have bothered with: look at the code and actually find out what's going on. He seems to have spent a lot more time on speculating about it than it would have taken (assuming he's even close to as competent as he claims) to find out some facts.

In any case, call me conceited if you will, but my advice would be against quoting his unsupported claim as being particularly authoritative about this particular subject.

[jcoffin]

I think blaming Corel for WordPerfect's fall from popularity is a bit of a stretch. WordPerfect handled the transition from MS-DOS to Windows quite poorly. The initial release of WP for Windows was so slow and buggy that it was next to unusable. Then WordPerfect got sold a couple of times, to Novell and Borland, both of which had other problems. There's also a lawsuit alleging that Microsoft used illegal tactics to gain market share for Word/Office (not sure whether it's true, but some of the allegations sound reasonable in any case).

The bottom line is that WordPerfect had lost virtually all its market share long before Corel got involved at all. I'm not sure that Corel will improve its sales, marketing, etc. -- but it's hard to imagine how they could make it a lot worse.

[agorabasta]

Agorabasta: What he's claiming strikes me as about as relevant as the price of tea in China, as the old saying went.

The thing I find relevant is whether the particular SW is relying completely on the OS memory management or does its own. I believe it's pretty normal for a memory-intensive SW to do its own memory management.

So the question really is how does Lr4 work with memory. Because ditching XP support may mean almost twice less work to do for that new version release.

[jcoffin]

The thing I find relevant is whether the particular SW is relying completely on the OS memory management or does its own. I believe it's pretty normal for a memory-intensive SW to do its own memory management.

Essentially all software does memory management of its own. It'll have an allocator that gets a big chunk of memory from the OS, and then divvies that up into smaller pieces for use by the rest of the code. As I said, LR does use malloc and free, which do exactly this.

This, however, is provided by Microsoft with the compiler -- Adobe didn't develop it at all. While Adobe certainly could write code that would bypass these and talk to the OS directly, I see no evidence that they've actually done so, nor any hint that if they had it would be affected by the OS's granularity (the most common reason to do this is to use VirtualAlloc, which hasn't changed).

I have to admit I'm quite lost as to why you (or anybody) would continue to pursue this idea that it's somehow about memory management based on pure speculation, when I've already pointed to a logical, straightforward explanation based on real evidence. Perhaps you'd find it more believable if you looked at the evidence directly yourself.

Fortunately, that's pretty easy to do. Start by downloading dependency walker. Run that and it'll ask you want executable to open. Tell it to open lightroom.exe. That will give an error you can ignore -- just click "ok". Then it will come up with a screen like this:



Looking to the left, you can see I've highlighted kernel32.dll (the Windows kernel). If you look on the right, you'll see that "AcquireSRWLockExclusive" and "AcquireSRWLockShared" are both shown in teal-green, indicating that they're used by this executable (the alternative being grey, such AddConsoleAliasA, shown at the bottom of the same list).

If you go to MSDN, and scroll to (near) the bottom of the page, you'll see that the minimum supported OS for these functions is Windows Vista (or Server 2008).

If you really insist on looking into the memory management, you can highlight MSVCR80.DLL (Microsoft Visual C++ Runtime, version 8.0) on the left, and scroll down to "malloc" to see that it's also being used:



That does not, of course, prove that it cannot/may not use some other memory management as well (e.g., in kernel32.dll, LocalAlloc and LocalFree are used -- certainly by malloc, but possibly by something else as well).

Now, you can see quite directly at least one reason that LR4 really does require Windows Vista or newer. While it's barely possible that having made that decision anyway, Adobe could (possibly) have simplified some memory management code as well, but as far as I can see this is purely speculative. If you look around, you'll find a number of things that people typically do to optimize memory allocation in C++. For example, you might look at the Loki small object allocator, or the Boost pool allocators. What you'll quickly find is that even these are completely isolated from details of memory management by the OS -- they'll port not just from Windows XP to Vista/7 without any difficulty, but also to Linux, BSD, MacOS, etc., without any difficulty either.

This gives a general idea of how likely you are to find memory management code in LR that would have required significant extra effort to continue working on XP: essentially no chance at all. Memory management as the reason for LR4 being restricted to Vista or newer is a red herring.

[agorabasta]

The existing XP installs are predominately 32bit, so there's no use looking into 64bit version.

There's one really new thing introduced in Lr4 - the automatic CA correction. It works by analysing the image geometry per colour channel and calculating the geometry corrections for the blue and red to converge with the green.
This new process needs a lot of memory during the calculations. And even after the calculations are done, it still consumes memory for additional 'layers' it creates. If you simply run automatic CA correction on JPEG files (means no other processing at all as opposed to the raw), the memory usage goes up to about 2GB after applying corrections to as few as only three 16Mp JPEGs.

But we still have a 32bit version of Lr4 that works OK on Win7 32bit. Based on that alone, I 'speculate' that some special memory management must be in place for 32bit OS's.

P.S. Here's a bit straight from the horse's mouth (Adobe) - NOTE: On the Mac platform we needed to make a similar decision to end support for systems that are not 64-bit capable.