I usually never participate in these discussions, but I feel like I should make an exception to speak up a little here. Just a few remarks:
I don't see the issue in using Photoshop with documentary goals in mind. Of course, one can use it to produce fabrications, but that also applies to any other image processing program.
I agree completely. The main problem is not with this or that software application. It's with image retouching and painting practices, as opposed to image processing based on documentary criteria. It's with arbitrary manipulations, as opposed to knowledge and understanding of the data. We don't have powerful painting tools and this makes painting more difficult in PI than in PS, but you can destroy your data nicely in both applications. I'm sure you already know this, but a more complete summary of our (my) opinions about this topic, including what I think about PS, can be found in
FAQ 1.11.
I do believe Photoshop handles 32 bit images, but due to the way Photoshop works internally, many processes do not support 32 bit modes.
I'll comment more on the 32-bit topic later, but much worse than that is the fact that it cannot work (correctly) with linear data. For this reason PS requires specific plugins to pre-stretch the linear data in order to import them, or pre-stretching the data in other applications.
I count 42 APOD's to ...
In my opinion, APODization does not certify per se the quality of an image in astrophotographic terms (indeed we can document this), and has more to do with how an image can be used to describe something relevant about science or nature, including concepts such as "opportunity", "spectacularity", and "WOW effect", among others. There are absolutely wonderful APOD images (many of them by members of this forum) and also (IMO) many mediocre and even terrible ones.
What APOD does have is a huge power to broadcast our images worldwide. We definitely
need APOD to show our images to thousands of people, even if APOD's purpose is not related to astrophotography, and this causes strange effects many times.
... use of PS for documenting professional observations
For a long time PS (and PS-like applications) has been the only tool available for image manipulation on a graphical desktop. Well, this is not really true, because image processing and graphical desktops were there before PS, but I refer to relatively easy-to-use graphical interfaces suitable for people that cannot develop their own tools. In my opinion, the fact that most of the people dedicated to transforming science data into images still use PS reflects just this, and also the fact that changes (both technical changes and mind changes) are difficult and require a lot of time and effort. They simply don't know (and in some cases don't look for) other ways.
The team of DSA/CAHA observers led by Vicent Peris is currently using PixInsight to process images acquired with professional instruments, including the 1.23 meter and 3.5 meter telescopes at
Calar Alto Observatory. You can see a small sample of their work on our
gallery. Much more important than that, this team is doing a continued research and development work to create innovative image processing techniques. Most of these techniques are the basis of present and future PixInsight tools, and some of them have been documented on our
processing examples and
tutorials sections.
Now, the fact that Photoshop processes need different code/variables to handle different bit depth images is rather dumb, but that's a different story.
Our little team, with a few self-made workstations, a couple laptops, a 2008' Mac Pro, working at home and at the university, and lots of good wine, has been able to develop a much better engine for PixInsight on four platforms in about eight years. Our PCL (PixInsight class library) has always been able to handle
any data type, including real and complex numeric data, to represent pixel samples. The latest version 2.0 of PCL, which we are about to release as an open-source library with PixInsight 1.8, allows you to handle pixel data in purely abstract terms with type-independent, type-safe and thread-safe pixel iterators. See for example the documentation (just uploaded this morning) for the
GenericImage class. With PixInsight 1.8, I have rewritten more than a 30% of the PixInsight Core application and a 90% of PCL since March this year. I cannot understand why other teams don't have the same (or more) mutation capabilities.