photoshop or Lightroom?

PS includes Camera RAW which does everything the LR Develop module does. LR includes a set of other tools (image organization, keywording, convenient print management tools, a pretty poor slideshow tool, a web gallery generator, a book maker--many suck compared to dedicated apps, but they work).

If you get PS, it also includes LR with the CC version, so you don't have to choose . $10 per month.

But I think we should mention a couple competitors.

Capture One is much better than LR and far more powerful. If I were forced to choose one, I would consider this a much more solid option (better image quality, works faster, more powerful). It has been around longer than LR and is a more well developed, professional level product.

Afinity Photo is a much less expensive alternative to PS. $40 or $50 total cost, mostly the same feature set and a few extra tools, a few improvements which make it easier to use, etc. Worth a look, especially for the price.

Personally, I use Capture One and PS. I own Afinity, but my actions and skills are all built in PS. If PS prices go up, I'll probably build my system in Affinity. If I were starting from scratch, I'd give Affinity the nod.

There is good video support for all these products from the manufacturers. Adobe has better third party support, but most of the skills transfer easily. Much of the Affinity working methods match PS.

BigAl007, thanks for your remarks. Let me rebut...

1. If each color sensel has 2^14 bits, each color in the triad can have one of 16384 levels.
   
2. So in combination, the triad of sensels can be translated to a R-G-B pixel which has a color which is one of 4.3 * 10^12 hues.
   
3. 2^16 color space is 65536 * 65536 * 65535, or 2.81 *10^14 total hues, or 64 times as many colors as the sensels can be captured and interpreted, or fundamental overkill -- even at 2^16 for each color of the triad.!
   
4. So going to 2^32 takes us to 4.29 Billion levels of each of the triad, or 7.92 * 10^28 total hues,
   or 1.8 * 10^16 times as many hues as the sensel themselves can capture! ...which to me is ludicrous levels of OVERKILL.
   

Wilt wrote in post #18363217
BigAl007, thanks for your remarks. Let me rebut...

1. If each color sensel has 2^14 bits, each color in the triad can have one of 16384 levels.
   
2. So in combination, the triad of sensels can be translated to a R-G-B pixel which has a color which is one of 4.3 * 10^12 hues.
   
3. 2^16 color space is 65536 * 65536 * 65535, or 2.81 *10^14 total hues, or 64 times as many colors as the sensels can be captured and interpreted, or fundamental overkill -- even at 2^16 for each color of the triad.!
   
4. So going to 2^32 takes us to 4.29 Billion levels of each of the triad, or 7.92 * 10^28 total hues,
   or 1.8 * 10^16 times as many hues as the sensel themselves can capture! ...which to me is ludicrous levels of OVERKILL.
   

EACH PIXEL has 1.8 * 10^16 more empty capacity.

Wilt you are failing to remember that each sensel's worth of data has no directly relateable colour information recorded in it. It is simply a value related the brightness at that location. If you convert each of those values back to a brightness value you get a monochrome image.

Now because you know that in front of the sensor there is a Bayer CFA with alternate rows of red/green and green/blue filters, for which you know the spectral responce, it becomes possible to calculate an RGB triplet value for each sensel location, by using the data from that sensel, and those surrounding it.

Now as part of that calculation suppose that you need to multiply two sensel values together. The computer architecture limits you to using either 8, 16, 32, or 64 bit data structures. Also don't forget that modern processors are designed to work in 64 bits, since that is the size to the hardware devices that actually perform the computations. We had 32 bit registers etc way back in the 80's, so even then working in 32 bit was normal.

So if I have two 14 bit numbers, I have to put them in a 16 bit container. I only get 15 bits to work with, since one bit is used for the sign (+-). Now when looking at this you have to consider what happens when you are dealing with numbers near the maximum possible value. Small values are not the problem. So you need to multiply 17203 by 16300, and the result is 280408900. But hold on, you only want me to use 15 bits to hold the value, so the largest value I can have is 32767. So I get an out of range error, and the program terminates, or at least does what it does in that situation.

So in order to prevent the overflow error you simply allocate the next size up chunk of memory to hold the result of your computation. So in this case the result of multiplying two 16 bit values is a 32 bit value.

One very simple answer to why this is important is White Balance. To apply WB to the RAW data you multiply the value from sensels with that colour filter by a constant value, for that particular lightsource. For the red or blue channel that can often be a value gteater than 2. If you hold the resulting values in 32 bit, you won't get an overflow on WB. This is useful if you ETTR and maximise the exposure, without saturating any sensel. If you limit yourself to using only 16 bit values you can reduce the maximum useable exposure by a stop or more.

As well as dealing with overflow issues it is possible to scale the data by chosing where within the 32 bits you chose to drop your 14 bits of data. This then allows you to have room for the computations not overflowing, and also for greater precision during the computations. This is good because you don't get rounding errors introduced at each step of the computation. You only have to deal with that at the point it is converted back to an 8 or 16 bit RGB triplet at the end of the computations.

To end with I will again point out that system architecture does most to set at what level most computations will be done. If the hardware is optimised to work with 32 bit wide chunks of data, then that is what you feed it. Feeding it 8 or 16 bit wide data just runs with empty bits anyway.

Oh and it can be perfectly possible to derive accurate 32 bit per channel RGB colour data from a 14 bit sensel based sensor. Mostly we don't bother, since it is far more information than we might make use of.

Since the vast majority of output devices struggle to present more than about 6 bits of image data to the viewer, is that a good reason to limit all photographic computations to 6 bit?

Alan

Thanks, that's what it was, the color space in Bridge was set to Adobe rgb and when changed to srgb the problem was solved.

I'm using Adobe Photoshop cs6 and was wandering if I need to switchroom to Lightroom as well. Thanks for the post.

My answer now is neither. I abandoned the CC ship last month. Too many other good choices out there such as Capture 1 Pro, On1 Photo RAW, Affinity Photo (but it does not have a DAM yet), Luminar (DAM should be arriving late this year or early 2018), ACDSee,......etc.

James Crockett wrote in post #18438619
I'm using Adobe Photoshop cs6 and was wandering if I need to switchroom to Lightroom as well. Thanks for the post.

Maybe! . It really depends on what you need in the way of asset management, do you need to organise and find images from a very large and diverse range of subjects, or even just from a large number of images? Bridge is a very good file manager especially if you use Adobe programs. Oh and Adobe now give it away, so you can now download and use the latest CC version, simply by registering with Adobe. It will still work with your older version of Ps. If you are feeling that you need more than Bridge can offer in the way of organising your images, then Lr may be well worth considering.

The Lr Develop module is simply ACR in a different skin, with a couple of very minor differences. The main difference with the Lr Develop module is the working colour space. In ACR you work using the default colour space, and you view the image and see the histogram associated with it. In Lr you can only work in it's own colour space, and that is the histogram that you see. It is a derivative of ProPhotoRGB. You can use the Soft Proofing tools to see and adjust the image using any colour space you like. That is pretty much the only difference between using ACR and Lr. Of course although Process Version 2012 is still current, there have been quite a few new tools added compared to the version of ACR that ships with PsCS6.

Lr's big strength is it's organisational system. Since all of the images that you import into Lr have their locations referenced by the database it becomes very easy to find and display them. I have noticed that in the latest version of Bridge it now has a feature to create Smart Collections. I tried this out, and it took Bridge over 24 hours to parse my image folders to create the collection. Accessing the same Smart Collection in Lr takes less than a second! It is this ability to quickly search for images, using multiple different methods to perform those searches is one of the real big things about Lr. That it also allows multiple versions of the same image, without the need to duplicate the original file is very helpful. Need a couple of different aspect ratio crops for different print sizes? simple create a Virtual Copy. Want a monochrome conversion? Well just create another VC. Oh I do think that Lr offers the best monochrome conversion of all the Adobe programs. Even now I will do work on an image in Ps, and then bring it back to Lr to do the mono conversion.

Although I mostly use the Library and Develop module I do also use Lr to add Location data to my images, since you can drag and drop them onto a map, and they use Google map for their map data. As well as location I also often use the Print module, I have found it to be by far the easiest system for printing photos, although it does take a little effort to figure it out. All of the other output modules are also reasonably useful, although I'm sure that there are probably better specialist bits of software that will do a better job if you use them a lot.

If you are looking for a comprehensive image management and processing tool then Lr is very good, especially if you are already used to processing your images using Bridge/ACR/Ps. Remember though that you won't be completely replacing Ps, since you will still need to use a pixel editing program with layers etc from time to time.

Alan

I have LR came with my Leica's but never warmed up to it. I like photoshop (CS6) started in the mid 1990s with PS3 IIRC.

I start with raw and do the basics there. If there is a block of images i shot in the same light I adjust the color on them all to match. Do other basics in raw and then save as tiffs or jpgs and then finish in CS6. I find it to be more like working in a darkroom and thus more intuitive for me and the way I work.

I use Lightroom along with the Nik Collection... finish off in Photoshop.

Truth be told, I don't know my way around Photoshop. I have a couple books on the latest version but only use them to research something. I really need to expand my knowledge of it.
I'm one who doesn't mind the CC subscription. It's $10 a month.... half the price of a meal at a fast food place. I never have to fuss about upgrading to a new version after a new camera or lens is released and I end up buying it.

Phoenixkh wrote in post #18439476
...Truth be told, I don't know my way around Photoshop. I have a couple books on the latest version but only use them to research something. I really need to expand my knowledge of it. ...

Google is your friend. Just google what you want to do and hundreds of tutorials pop up. Books are just so cumbersome and difficult to find what you need.

I use both. If I'm doing multiple edits from a shoot the I use LR. If I'm doing a few hobby shots I use PS. I still like to have total control of output sharpening which PS provides.

I'm still using CS6. If I did not have PS I would have to think about it because I'm not one for subscriptions.