Pages: 1 ... 14 15 [16] 17 18 ... 22   Go Down

Author Topic: If Thomas designed a new Photoshop for photographers now...  (Read 186715 times)

Schewe

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 6229
    • http:www.schewephoto.com
Re: If Thomas designed a new Photoshop for photographers now...
« Reply #300 on: May 22, 2013, 06:09:01 am »

BTW can you clarify the ACR doing the rendering whenever LR "edits in PS" that Eric mentioned? I think it is a pretty important issue as I described and maybe from an underlying "architecture" of the way these applications integrate as well I naively wonder.

Not 100% sure what you are referring to...if you are talking about LR5 being able to open a rendered image into Photoshop CC or earlier, it all depends. But, as long as you make sure you have LR 5+ render the image, any settings you apply in LR5 will carry over (they may not if you use the option "Render Anyway"–which isn't an optimal result).
Logged

Tim Lookingbill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2436
Re: If Thomas designed a new Photoshop for photographers now...
« Reply #301 on: May 22, 2013, 01:08:00 pm »

Thanks Jeff. I understood from other comments you made that there was a "variety of opinion" and like you I hope constructive commentary can assist in development by whomever can take the lead...as in nature vacuums dont exist but transiently....
BTW can you clarify the ACR doing the rendering whenever LR "edits in PS" that Eric mentioned? I think it is a pretty important issue as I described and maybe from an underlying "architecture" of the way these applications integrate as well I naively wonder.
PS I meant to thank Eric and Thomas (but no slight to Michael for hosting the great site) Im new here and have only seen the 3 of you in your great videos.

Check out what I previously posted earlier in this thread (with screengrabs) relaying this Raw Engine mismatch issue that affects preview quality appearance differences in Photoshop with LR4's PV2012 vs CS3 ACR PV2003 and CS5 ACR PV2010.

It's all about the preview quality rendering between the parametric generated preview and what appears in Photoshop at different zoom views with regard to the appearance of color and sharpness. 100% zoom is quite difficult to assess image quality on high resolution images.

This is another reason Photoshop is so important for me especially in CS3 ACR 4.6 so I could get more accurate to print views at zoom levels that showed the entire frame of the image over 100% views which is like looking at the image with a magnifying glass in both PS/ACR/LR.

Something odd lately I've noticed after downloading and using LR4 with its new PV2012 and generally improved main panel previews over CS3 Bridge's is that now I'm getting the same level of quality previews in CS3 Bridge's main preview pane on SOME folders of images. Apparently either LR4's preview generator has affected Bridge's cached previews or enacted Preferences that never took hold with regard to High Quality Preview settings. Whatever it is I've noticed a change in Bridge CS3 Main Preview pane which now shows sharpening and correct color saturation when it didn't used to, but not for all folders.
« Last Edit: May 22, 2013, 01:10:59 pm by Tim Lookingbill »
Logged

mornellas

  • Newbie
  • *
  • Offline Offline
  • Posts: 3
Re: If Thomas designed a new Photoshop for photographers now...
« Reply #302 on: May 22, 2013, 02:48:13 pm »

As I sit here in front of my monitor pondering the reasons why, simple things come to mind with wide eyes. We have to look past the rational of one's needs and explore the WHY's of the request. If we do that, you shall find there are many needs related to having the ability to turn things on or off within an application.

To build a brand new application seems to me, a large effort and investment. That of which, I really question the value considering that all we need is already built for the most part. Seems that having to regrind a new application is double work.

Photoshop is what it is. Good, bad or indifferent. Realistically, if we had the ability to gray out or turn off features or sets of features pre determined by a consensus - with the ability to customize the relationship of features to some extent, then you now have the core goal addressed.

To build an application and omit features, just leads to feature requests for the new app. As one can imagine, this turns into creating an exercise in square circles. Having the ability to turn features on or off as needed is a more desirable, practical and realistic goal.

Any other way, is a waste of time for Adobe and its users.

mike
« Last Edit: May 22, 2013, 02:56:57 pm by mornellas »
Logged

LKaven

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1060
Re: If Thomas designed a new Photoshop for photographers now...
« Reply #303 on: May 22, 2013, 07:00:06 pm »

To build a brand new application seems to me, a large effort and investment. That of which, I really question the value considering that all we need is already built for the most part. [...]

Photoshop is what it is. Good, bad or indifferent. [...]

Any other way, is a waste of time for Adobe and its users.

I think this depends upon the scope of your imagination for what an image tool could be, and your understanding of what are photoshop's shortcomings.  For me it could be many things, and its shortcomings are also many.  While there might be only so many ways to put brush to pixel, there are many ways to construct an image tool that have come along since photoshop was invented.  It might have been good enough for dear old dad, but it isn't good enough today.  If you can invent something new and steal photoshop's user base, then it's worth the money and time.

mornellas

  • Newbie
  • *
  • Offline Offline
  • Posts: 3
Re: If Thomas designed a new Photoshop for photographers now...
« Reply #304 on: May 22, 2013, 07:31:50 pm »

All valid points.

What I'm trying to get across is that applications have grown so much that the maturity level is robust enough to turn things on and off.

There may be other reasons to create new applications. Some reasons may be engineering, marketing - some may be political and some more likely shall be financial. Adobes ship has sailed and keeping it afloat is what I believe is the primary reason for a new app. The challenge they now face is coming up with new ways to skin the same 85% dead cat so they can stay in business.  AKA - Creative Cloud.

Everyone was complaining about not having a Swiss Army Knife. Now that you have it, we complain about it having too many tools.

Modular software will be the future that Adobe and other software manufactures can capitalize on without alienating its user base. The Cloud will be more like a hurricane for Adobe, if they screw up the internet ping authorization.
Logged

madmanchan

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2115
    • Web
Re: If Thomas designed a new Photoshop for photographers now...
« Reply #305 on: May 22, 2013, 08:02:23 pm »

To clarify:  When Lightroom uses "Edit in Photoshop" to send images to Ps without requiring writing an intermediate TIFF/PSD out to disk, this requires using the Camera Raw plug-in.  No, it doesn't call up the ACR interface, of course (i.e., this is all happening behind the scenes), but it is the one time when it's using the ACR plug-in instead of Lightroom's own internal imaging logic.  The reason this matters is that if you have an older version of ACR that doesn't support the features you're trying to use in Lr's Develop, then the handoff from Lr to Ps won't work properly (at that point, you'd have to render your Develop edits into an intermediate PSD/TIFF in order for the edits to be reflected properly in the image you see in Ps).
Logged
Eric Chan

judymcintosh

  • Newbie
  • *
  • Offline Offline
  • Posts: 15
Re: If Thomas designed a new Photoshop for photographers now...
« Reply #306 on: May 23, 2013, 06:15:46 am »

Thanks Eric, thats really clear and significant for the reason you mention.
My request for this thread is that any future for Lr or its offspring would ensure its raw conversion is passed to what for many (me at least) would be a more ancient (pre CC) Ps application  with its raw converter (ACR) sitting in the background. It needn't be a design feature of course (just more convenient), just a workflow for users to save to a folder as PSD/TIFF and then open those in Ps. That is now what I will be doing (Lr4 and CS5), as Id mistaken the "Render using Lightroom" to mean Lightroom would do the raw conversion.
Im sure I've gone a generation back on raw conversion for those photos that I decided to take to Ps unknowingly, and been playing with the lowest common denominator between the two for raw conversion.For me Lr generations have been worth the difference to upgrade, but Ps not. The changes in the payment model may actually work better for me ironically through this better understanding and think "beyond Ps upgrades". Heat gives way to light.......
Logged

Tim Lookingbill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2436
Re: If Thomas designed a new Photoshop for photographers now...
« Reply #307 on: May 23, 2013, 02:48:14 pm »

Quote
When Lightroom uses "Edit in Photoshop" to send images to Ps without requiring writing an intermediate TIFF/PSD out to disk, this requires using the Camera Raw plug-in.  No, it doesn't call up the ACR interface, of course (i.e., this is all happening behind the scenes), but it is the one time when it's using the ACR plug-in instead of Lightroom's own internal imaging logic.

The reason for the bold highlights, Eric, is to point out the fact Lightroom uses plug-ins as well which made me wonder why the code couldn't be changed so that there would be an option within the "Edit In Photoshop" dialog box to allow selecting which ever "Imaging Logic" is most current (or desired) so a bitmap copy isn't created thus allowing "Edit In Photoshop" to act in the same manner it does starting out in Bridge>ACR>Photoshop.

Why does Photoshop's plug-in get to override LR this way? Would it be easy to make a change like that for current users of CS5 PS and older and in future CC upgrades when LR uses older "Imaging Logic"?

Once parametric edits are rendered to pixels and previewed in Photoshop those instructions are no longer needed and so an option on priority of which app controls the look of the preview should be given to the source, the app that originally created the parametric instructions.
« Last Edit: May 23, 2013, 02:53:44 pm by Tim Lookingbill »
Logged

aduke

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 446
Re: If Thomas designed a new Photoshop for photographers now...
« Reply #308 on: May 23, 2013, 06:28:37 pm »

I just performed the following experiment.

In LR5, I chose an image and applied a very strong radial filter to it, severely darkening most of the image. I then chose Edit-in Photoshop, via the menu (or rather,  by right-click the image and chose edit in Photoshop.) LR gave a message saying that there was a conflict between the ACR levels in LR and Photoshop, and asking what I wanted to do. I told it to render using lightroom.

In PS, the image appeared, looking just as it did in LR, with a bright spot in the middle of a sea of black.

Returning to LR, the tif was deleted. I again told LR to edit in PS by using Ctrl-E. Again the message appeared and again I said to render in LR, and again the expected image appeared. Back in LR it was deleted again.

Returning to LR  and deleting the image again, I once more said to edit in Photoshop. The same message appeared, but this time I replied to Open Anyway, causing the image to be rendered in PS. This time the image looked as if there was no radial image.

I am now convinced the the choice to Render Using Lightroom causes lightroom to do exactly that, creating a tif that is passed to PS. Also, that the Render Anyway choice sends the raw file to PS along with the parametric version of the settings and the image was rendered in PS. It looked somewhat like the base image but without the radial filter.

Alan
Logged

MHMG

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1285
Re: If Thomas designed a new Photoshop for photographers now...
« Reply #309 on: May 23, 2013, 10:15:07 pm »

So, here's a PS feature I just used today, that until today, I didn't realize just how often I have come to rely on it. I wanted to look at three different print versions of an image, ie. one softproofed on HN photo rag using Peceptual rendering, another softproofed on HN photo rag using Relative rendering with BPC, and still another version of the same image softproofed to an altogether different paper, for example, Canson Platine. Sometimes, I want to look at variations of sharpening settings at a particular magnification. PS's Arrange/tile plus "match" features let's you do this in a really elegant way. LR has a side-by-side compare feature of same image but no way that I know of to compare more than two versions of the same image in a tiled scene on screen. PS will tile 3, 4, etc, images side by side and let you set unique edit/output renderings to each image. I know of no other software at the moment that can do this. So, Jeff, if you have the ear of some skunkworks software programming team that wants to reinvent the image editing process for us photographers, that would be a great feature to include/retain in the next incarnation.

cheers,
Mark
http://www.aardenburg-imaging.com
« Last Edit: May 23, 2013, 10:34:55 pm by MHMG »
Logged

aduke

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 446
Re: If Thomas designed a new Photoshop for photographers now...
« Reply #310 on: May 24, 2013, 12:09:54 am »

So, here's a PS feature I just used today, that until today, I didn't realize just how often I have come to rely on it. I wanted to look at three different print versions of an image, ie. one softproofed on HN photo rag using Peceptual rendering, another softproofed on HN photo rag using Relative rendering with BPC, and still another version of the same image softproofed to an altogether different paper, for example, Canson Platine. Sometimes, I want to look at variations of sharpening settings at a particular magnification. PS's Arrange/tile plus "match" features let's you do this in a really elegant way. LR has a side-by-side compare feature of same image but no way that I know of to compare more than two versions of the same image in a tiled scene on screen. PS will tile 3, 4, etc, images side by side and let you set unique edit/output renderings to each image. I know of no other software at the moment that can do this. So, Jeff, if you have the ear of some skunkworks software programming team that wants to reinvent the image editing process for us photographers, that would be a great feature to include/retain in the next incarnation.

cheers,
Mark
http://www.aardenburg-imaging.com

If you make several virtual copies of an image and then make individual and different changes to each, you can see all or most of them on a single screen by selecting all of them and entering Survey Mode (hot-key N).

Alan
Logged

Tim Lookingbill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2436
Re: If Thomas designed a new Photoshop for photographers now...
« Reply #311 on: May 24, 2013, 12:20:50 pm »

Quote
I am now convinced the the choice to Render Using Lightroom causes lightroom to do exactly that, creating a tif that is passed to PS. Also, that the Render Anyway choice sends the raw file to PS along with the parametric version of the settings and the image was rendered in PS. It looked somewhat like the base image but without the radial filter.

Just for clarification what version of Photoshop were you using?
Logged

aduke

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 446
Re: If Thomas designed a new Photoshop for photographers now...
« Reply #312 on: May 24, 2013, 12:31:10 pm »

Tim:

Sorry for not noting that: CS5!

Alan
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: If Thomas designed a new Photoshop for photographers now...
« Reply #313 on: May 24, 2013, 01:25:45 pm »

I am now convinced the the choice to Render Using Lightroom causes lightroom to do exactly that, creating a tif that is passed to PS.

Yes, when you export OR LR tells you the version of ACR isn't on parity and you pick Render using LR. Usually ACR does the rendering not LR when you use Edit in Photoshop. Been that way for years but at least version 1 used to have LR do the rendering. Later Adobe just made a call to Photoshop (and ACR) to do this. If the two are on version parity, LR doesn't render, ACR does.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Tim Lookingbill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2436
Re: If Thomas designed a new Photoshop for photographers now...
« Reply #314 on: May 24, 2013, 02:44:01 pm »

Yes, when you export OR LR tells you the version of ACR isn't on parity and you pick Render using LR. Usually ACR does the rendering not LR when you use Edit in Photoshop. Been that way for years but at least version 1 used to have LR do the rendering. Later Adobe just made a call to Photoshop (and ACR) to do this. If the two are on version parity, LR doesn't render, ACR does.

So then it's possible to switch it back and give the rendering option to LR, right?

Wish I knew the reason why this was changed or why it's set up this way.
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: If Thomas designed a new Photoshop for photographers now...
« Reply #315 on: May 24, 2013, 02:48:44 pm »

So then it's possible to switch it back and give the rendering option to LR, right?

Sure, use Export.

The current behavior where ACR renders is a lot faster and you end up in Photoshop which is kind of what you asked for when you say "Edit in Photoshop". Oh, and you get that edited version back into the library after you save. If you don't have the latest version of ACR, you want to use the Export command, unless you want to cripple the editing you've done with newer software, just to use the Edit In Photoshop option.

What LR doesn't do is force you to upgrade to the newer version of ACR. But you do have to use Export.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

JohnHeerema

  • Full Member
  • ***
  • Offline Offline
  • Posts: 241
  • Dr. John Heerema
    • http://www.heerema.ca
Re: If Thomas designed a new Photoshop for photographers now...
« Reply #316 on: May 24, 2013, 10:08:11 pm »

When Adobe decided to improve it’s revenues by converting purchasers into renters earlier this month, I found myself wondering what I would do if I had the opportunity to create an alternative to Photoshop.

The question has been percolating in my head for a while now, and when I discovered this thread, I decided to try sharing some of my thoughts, despite the conventional wisdom that it is pointless to post into a thread that is already several pages long.

By way of background, I’ve been using Photoshop for a very long time. As much as I like Lightroom, I use Photoshop at some point in the production of almost all my exhibition images. My technical expertise is in software development and digital signal processing. I was pretty interested in Live Picture when it was introduced, until I saw the price.

If I could, I’d want to hire about six particular people from Adobe for the project (naturally, that would include Mr. Knoll, and a few other key people). That would mean total clean-room development, but starting with a fresh slate might not be such a bad thing.  There’s a lot of pretty well thought out stuff in Photoshop, so building something better would be far from trivial – but doable with the right people and resources, IMHO.

When I edit images, I think in terms of regions of interest, and transformations on them.
Photoshop has much more precise ways to select a region of interest than Lightroom does, wherein lies much of its appeal for me. In Photoshop, selections can be either vector-based, or mask-based. Some tasks lend themselves to one kind of selection, and some to another. Either way, the partial selection (variable transparency) concept is very nice.

Smart filters in Photoshop, and adjustment brushes in Lightroom have the desirable ability to be modified at any point, which is something I’d like to generalize to all image operations in a Photoshop replacement.

The layer paradigm seems natural to me, perhaps because I think of layers in terms of the very efficient bitblt operations that are performed between them. I’ve noticed though, that a surprising number of people don’t find them intuitive.

Whether layers are intuitive or not, one of the things that almost everyone does in Photoshop from time to time is “copy merged to new layer”, which breaks the ability to treat the layers beneath the new layer as being editable. I’d like to make that unnecessary.

I’ve been thinking of an alternative approach, in which regions of interest don’t have to fit into the layer stack approach. Perhaps you’re editing a photo of someone, and you are adding local contrast to her left iris. You might want to do a few things to the same selection.

I’d like to be able to define “left iris” as a named selection, including a bit of feathering around the edges, and then be able to perform one or more transformations on that selection. The selection and its transformations would be one “thing” in a collection of such things. Perhaps they would look like a layer stack, as they do in Photoshop, but they wouldn’t have to. They could be items in a list, nodes in a node tree, pages in a book, or something entirely new.  Whatever they looked like, you could presumably click on something, and immediately see what part of the image it affected, and be able to modify any of the transformations that had been made on it. Lightroom sort of takes this approach, but the Lightroom approach doesn’t have a useful way to organize the adjustments to an image, so it bogs down after a while: there are just too many pins on the image to tell what’s what.

I’d like the selection and transformations to survive through other operations that happened to include the same region of interest. For example, if I were to slightly enlarge the entire eye, I’d like the transformations on the iris to remain editable.  If I had removed distracting reflections in a few windows in a photo of a building, and then applied a transformation on the whole building to straighten its vertical lines, I’d still like to be able to modify the transformations on the individual windows.

I don’t see any reason that operations that we’ve come to think of as being pixel oriented have to be stored as bitmaps. Filters such as liquefy, and content-aware healing can still be thought of as being essentially parametric.

Naturally, I think of “snapshots”, and alternative branches as being intrinsic functionality (think of what a version control system does).

For the sake of efficiency it might very well be that the software would have to create a series of bitmaps as part of its imaging processing pipeline (I think that it would) – but I see that as an efficiency optimization, rather than as a necessary part of the visual paradigm.  So even if the internal representation were something like bitmaps and bitblt operations between them, you’d never have a need to make an explicit new bitmap of a particular state via “Merge Visible” and its variants.


Logged

Schewe

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 6229
    • http:www.schewephoto.com
Re: If Thomas designed a new Photoshop for photographers now...
« Reply #317 on: May 24, 2013, 11:48:31 pm »

Naturally, I think of “snapshots”, and alternative branches as being intrinsic functionality (think of what a version control system does).

Ironic you said this because the genesis of Lightoom was a sandbox project Hamburg started called PixelToy (sometimes refereed to Schewe Paint by Mark) which essentially leveraged Photoshop history and snapshot functionality (I had a large'ish impact on history when Mark first wrote it for Photoshop 5).

PixelToy was an ability to do a bunch of stuff to an image, take a snapshot and use the snapshot to blend by brush, back into the image. Each snapshot could be edited...for further functionality.

Sadly, when Mark was convinced to to go a database driven app, the snapshot painting fell by the wayside. And history in Lightroom isn't related, not is there an ability to blend between LR snapshots.

Maybe something for Mark to take a 2nd look at.

BTW, I just bought a copy of Live Picture 2.6 on Ebay for $ .99 (shipping and handling was $10.95). I've got an old G4 laptop with 10.4 and classic running OS 9.x on it. I'm gonna try to install it and play with Live Picture to try to remember how it worked.

I still have my old LP 1.3 and the $3,499 dongle but I don't think I have a machine it would run on (and LP 2.6 was much better).
Logged

LKaven

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1060
Re: If Thomas designed a new Photoshop for photographers now...
« Reply #318 on: May 24, 2013, 11:55:29 pm »

John, why not adopt an N-dimensional dataflow processing model for your architecture?  

Layers are just a 1-dimensional dataflow processing model (aka, "node based"), and you can always implement layers within a part of your N-dimensional dataflow model (where N = 1 dimension).  Everything can be a smart filter, and baking in intermediate layers can be an option.  You can accomplish many kinds of things using N-dimensions that you can't accomplish in one dimension, e.g., making multiple uses of a single source with indefinite non-destructive editing and undo, etc.

JohnHeerema

  • Full Member
  • ***
  • Offline Offline
  • Posts: 241
  • Dr. John Heerema
    • http://www.heerema.ca
Re: If Thomas designed a new Photoshop for photographers now...
« Reply #319 on: May 25, 2013, 01:24:35 am »

Quote
why not adopt an N-dimensional dataflow processing model

I like that. The trick might be creating a user interface that was intuitive for photographers - I'm not sure that I see photographers warming up to something that looked too much like a data flow diagram.

I would think that a lot of transformations would be order-independent, but that you'd need a good way to specify when one transformation has to be done before (or after) another transformation.
 
Logged
Pages: 1 ... 14 15 [16] 17 18 ... 22   Go Up