7 Steps for Editing Your Photos

Archived from groups: rec.photo.digital (More info?)

In article <1106063554.499065.72990@f14g2000cwb.googlegroups.com>,
<gary_hendricks@digital-music-guide.com> wrote:


Who the hell do you think you are - the Photo Answer Man?

Archived from groups: rec.photo.digital (More info?)

In article <1106063554.499065.72990@f14g2000cwb.googlegroups.com>,
gary_hendricks@digital-music-guide.com says...
>
>When editing digital photos, it helps to have a standard workflow.
>Knowing the right order to apply your editing tools helps you get the
>best results.
>1. Edit in Lossless Format
>Some file formats, such as JPEG, lose quality every time you save an
>edit. This is called a "lossy" format. If you are performing a long
>series of edits, you may actually make things worse despite your
>efforts. The opposite type of format is "lossless." With a lossless
>format, such as TIFF, no quality is lost when you make edits.
>
>2. The Initial Clean-Up
>Some edits, such as cleaning up noise and correcting lens distortions,
>are best performed at the beginning so you do not exaggerate them
>during later steps. There was no noise in the above example, so this
>step was not necessary.

[SNIP]

Gary, thanks for taking the time to compile and post this, as it might help
many just starting into digital image processing.

I have one problem with the order, however. I base this on the type of work
that I do (advertising/architectural), so it might not make a difference with
others' images. If one will be manipulating the image(s) with Clone/Healing (
Photoshop), then the noise reduction should come, just before the Sharpening,
as you want any textures that appear in the image, to be treated the same, so
nothing new is introduced to a image after, say treatment with NeatImage. I do
my Adjustment Layers for Color, Sat, Hue, etc. first, then make those
inactive, while I Clone, whatever, then re-activate Adjustment Layers, Save_As
PSD for final, Flatten and run NeatImage, then Sharpen, and finally Size for
output. Other than that quibble, I like what you have written.



>------------------------------------------
>Gary Hendricks
>http://www.basic-digital-photography.com

Hunt

Archived from groups: rec.photo.digital (More info?)

"3. Adjust the Color
4. Saturation and Hue Adjustment"

I do these while the image is still in RAW format (e.g. before TIFF).
This has to do with the tools at my disposal. I also find that almost
all of my color issues are White Balance issues and my RAW tools enable
me to not just adjust the multipliers individually on R, G, and B, but
also adjust the black points and gain on each channel individually as
well. This puts and 4 before your 1 and 2, however, I would assert
that RAW is just as lossless as TIFF.

Archived from groups: rec.photo.digital (More info?)

On Tue, 18 Jan 2005 15:52:34 +0000, gary_hendricks wrote:

> When editing digital photos, it helps to have a standard workflow.
> Knowing the right order to apply your editing tools helps you get the
> best results.
> 1. Edit in Lossless Format
> Some file formats, such as JPEG, lose quality every time you save an
> edit. This is called a "lossy" format. If you are performing a long
> series of edits, you may actually make things worse despite your
> efforts. The opposite type of format is "lossless." With a lossless
> format, such as TIFF, no quality is lost when you make edits.
>
Gary, Thanks for the tips. My D-rebel saves in jpeg. I know I can save
them in raw but if I save them in default jpeg, is it OK to convert them
first to something like GIF, do the editing & then convert back to jpeg
for storing ? I can of course store them in GIF as well. My PC being is
rather old takes a much longer time to load & manipulate TIFF files
compaed to GIF or Jpeg.

--

Gautam Majumdar

Please send e-mails to gmajumdar@freeuk.com

Archived from groups: rec.photo.digital (More info?)

GIF is a lossy format ... and very poor for photographs.

Convert them to something like TIFF (using LZW compression, if you like),
PhotoShop PSD, or PNG that is *not* a lossy format.

Do *not* "convert them back to JPEG" for storing ... the above referenced
file types are all around better for use, archiving or long term storage.




"Gautam Majumdar" <gmajumdar@XSPAMfreeuk.com> wrote in message
news:wneHd.167146$48.78964@fe1.news.blueyonder.co.uk...
..
> >
> Gary, Thanks for the tips. My D-rebel saves in jpeg. I know I can save
> them in raw but if I save them in default jpeg, is it OK to convert them
> first to something like GIF, do the editing & then convert back to jpeg
> for storing ? I can of course store them in GIF as well. My PC being is
> rather old takes a much longer time to load & manipulate TIFF files
> compaed to GIF or Jpeg.
>
> --
>
> Gautam Majumdar
>
> Please send e-mails to gmajumdar@freeuk.com

Archived from groups: rec.photo.digital (More info?)

Randall Ainsworth wrote:
>
> In article <1106063554.499065.72990@f14g2000cwb.googlegroups.com>,
> <gary_hendricks@digital-music-guide.com> wrote:
>
> Who the hell do you think you are - the Photo Answer Man?

the "really simple answers for clueless newbies" answerman.

his answers are far poorer than kodaks fireworks answers...

Archived from groups: rec.photo.digital (More info?)

In message <JPeHd.2007$CI6.1746@trnddc06>,
"RSD99" <rsdwla.NOSPAM@gte.net> wrote:

>GIF is a lossy format ... and very poor for photographs.

GIF is not a "lossy format" per se. GIF is a palette-based format, and
used in that context, is not lossy. It is only lossy when used beyond
its scope; to convey true-color images with more than 256 colors. It
can convey greyscale photos quite well, as they only need 256 shades.
--

<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
John P Sheehy <JPS@no.komm>
><<> <>>< <>>< ><<> <>>< ><<> ><<> <>><

Archived from groups: rec.photo.digital (More info?)

When used with photos ... which actually **is** the subject of this
discussion ... GIF **is** a lossy format.

It converts everything to a fixed pallet of 256 colors ... which may (or
may NOT) have 256 shades of gray ... depending on how it is saved, and from
what program it is saved. If it is saved using a "Fixed Pallet" (such as
"The Windows Pallet, for example), it may have only 6 to 9 shades of gray!

It is definitely ***NOT*** recommended, under any circumstances, for
photographic images.




<JPS@no.komm> wrote in message
news:61jru09am1n2oug640u475v6s12ufu04h8@4ax.com...
> In message <JPeHd.2007$CI6.1746@trnddc06>,
> "RSD99" <rsdwla.NOSPAM@gte.net> wrote:
>
> GIF is not a "lossy format" per se. GIF is a palette-based format, and
> used in that context, is not lossy. It is only lossy when used beyond
> its scope; to convey true-color images with more than 256 colors. It
> can convey greyscale photos quite well, as they only need 256 shades.
> --
>
> <>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
> John P Sheehy <JPS@no.komm>
> ><<> <>>< <>>< ><<> <>>< ><<> ><<> <>><

Archived from groups: rec.photo.digital (More info?)

gary_hendricks@digital-music-guide.com wrote:

> When editing digital photos, it helps to have a standard workflow.
> Knowing the right order to apply your editing tools helps you get the
> best results.
> 1. Edit in Lossless Format
> Some file formats, such as JPEG, lose quality every time you save an
> edit. This is called a "lossy" format. If you are performing a long
> series of edits, you may actually make things worse despite your
> efforts. The opposite type of format is "lossless." With a lossless
> format, such as TIFF, no quality is lost when you make edits.

I agree. But I would argue that any editing in 8-bit mode is
lossy: intensity lossy. The first step I do is:
A) convert raw to 16-bit tif (with any necessary color
balance, contrast), or
B) convert 8-bit jpeg to 16-bit tif
>
> 2. The Initial Clean-Up
> Some edits, such as cleaning up noise and correcting lens distortions,
> are best performed at the beginning so you do not exaggerate them
> during later steps. There was no noise in the above example, so this
> step was not necessary.

2) Adjust levels using the levels tool. You can't clean up if the
image is too dark.

3) dodge and burn to get the image withing range for viewing
and printing.

4) contrast stretching (this affects apparent color).
>
> 3. Adjust the Color
> This involves adjusting the RGB (Red, Green and Blue) or CMYK (Cyan,
> Magenta, Yellow and Black) values. Until you learn the theory of color
> adjustments, it is best to make very small changes and see how they
> look. Often, these adjustments lighten the image and reveal additional
> noise, so a bit more clean-up may be required.
>
> 4. Saturation and Hue Adjustment
> Saturation and hue affect the appearance and richness of the colors in
> your photo. You will usually want to increase color richness. Again,
> the best results are normally had by making small adjustments. After
> this step, re-evaluate your color adjustments to ensure they still look
> right.
>
> 5. Editing
> You can now perform any final edits such as removing blemishes from
> skin, whitening teeth, smoothing wrinkles and so on. Often, the image
> areas that need editing are quite small relative to the whole picture.
> For best results, zoom in and work on the picture close up. This way,
> you will be less likely to make unseemly blotches instead of fixes. If
> major edits are made at this stage, some additional color and
> saturation tweaks may be needed.
>
> 6. Scaling
> You can now try to apply any final cropping and resizing. Remember not
> to crop too close to important subject matter. If you leave plenty of
> space around them, your photo will look more balanced and you will be
> less likely to cover things up when framing. Also, remember to consider
> pixel depth and the rules of thumb for printing before making your
> photo too big. Minimum print quality requires 150 PPI (pixels per
> inch). Maximum quality, which is recommended for enlargements, requires
> 300 PPI.
>
> 7. Sharpening
> Sharpening is the final step in the process. You can sharpen any areas
> that might benefit from looking crisper. The reason this step is left
> to last is that sharpening can exaggerate other problems. Because of
> the potential side effects of sharpening, it is usually best to select
> only specific areas for sharpening, usually the main subjects.

You may need editing after sharpening to fix sharpening induced
artifacts. There is an iterative loop back up to my #2.

Finally, for contrast stretching, only use levels and curves
tools (in photoshop); others are additive tools and have
undesirable side effects. Levels and curves are multiplicative
tools. (at least in photoshop)

Roger

Archived from groups: rec.photo.digital (More info?)

RSD99 wrote:

> IMHO: Loss of color depth ... is still a loss. Therefore, the GIF
format is
> a lossy storage format.

Then your opinion isn't useful. It is commonly understood that "lossy"
etc is applied to the encoder -- not to whatever processing system is
in front of it. Anything else makes the whole distinction worthless.
Is a PPM "lossy" because it is 8-bit encoded gamma data that originally
came from (say) 16 bit linear information? Can we blame a GIF decoder
for being "lossy" when it faithfully reproduces the encoder input,
exactly?

Archived from groups: rec.photo.digital (More info?)

Stu Dapples wrote:

> "Gautam Majumdar" <gmajumdar@XSPAMfreeuk.com> wrote in message

>> Gary, Thanks for the tips. My D-rebel saves in jpeg. I know I can
save
>> them in raw but if I save them in default jpeg, is it OK to convert
them
>> first to something like GIF, do the editing & then convert back to
jpeg
>
> GIF??? This is an attempt at humour right?
No, the entity is trolling. Isn't it obvious?

Archived from groups: rec.photo.digital (More info?)

JPS@no.komm wrote:

> For certain greyscale photographic images, GIF will compress a greyscale
> image better than a high quality JPEG, with better accuracy.

Yes, I agree. I forgot to mention that.
Also, some photo icons (thumbnails) can be smaller as gifs
than as jpegs. But for real images 256 colors is simply
not enough.

Roger

Archived from groups: rec.photo.digital (More info?)

OK ... have it your way. Immediately go to your computer, open and resave
**all** of your images as GIF files, and **DELETE** the originals ...
whether they be RAW, TIFF, PSD, or even JPEG files.

I mean ALL OF YOUR ORIGINAL IMAGE FILES!

I dare you!

= = = = =

I think you need to look up the definition of the word

Loss

There is no such common understanding. Loss is just that, and it is NOT
limited to the encoding-decoding stage(s) of a GIF file format encoder.

Further, you stated:
"...
Can we blame a GIF decoder
for being "lossy" when it faithfully reproduces the encoder input,
exactly?
..."

That is not the consideration here. We **can** blame the encoder-decoder
(combination) when the output is not equivalent to the input. In such a
case ... the transmission method / media / file format is **lossy**.

Archived from groups: rec.photo.digital (More info?)

In message <ZxAHd.6968$IP6.6536@trnddc05>,
"RSD99" <rsdwla.NOSPAM@gte.net> wrote:

>"Roger N. Clark" posted:
>"...
>Gif is not a lossy format. It is a lossless compression format.
>But it is limited to 256 colors, so it loses color accuracy
>..."
>
>With all due respects ... you can't have it both ways.
>
>While it is true that the GIF file format does not have any "compression
>losses" ... it does have the losses associated with converting a 24 bit,
>three color image (16+ million colors) to a palleted 8-bit (256 color)
>indexed color image.
>
>IMHO: Loss of color depth ... is still a loss. Therefore, the GIF format is
>a lossy storage format.

So, by your logic, text mode is lossy, because it doesn't handle MSWord
..doc files?


--

<>>< ><<> ><<> <>>< ><<> <>>< <>>< ><<>
John P Sheehy <JPS@no.komm>
><<> <>>< <>>< ><<> <>>< ><<> ><<> <>><

Archived from groups: rec.photo.digital (More info?)

RSD99 wrote:

> I think you need to look up the definition of the word
>
> Loss

You have made a baseless claim and now insist everyone re-define a word
just so you don't look stupid? What kind of argument is this?

> There is no such common understanding. Loss is just that, and it is
NOT
> limited to the encoding-decoding stage(s) of a GIF file format
encoder.

There is no loss between a GIF encoder and decoder -- this is the
working definition of "lossless" for any signal path, despite your
kooky claims to the contrary. What goes in comes out, exactly. Your
problem is demanding that processing stages _PRIOR_ to encoding are to
be considered part of the "encoder". As I pointed out (and will again,
below), such an operating definition leads to nonsense.

> Further, you stated:
> "...
> Can we blame a GIF decoder
> for being "lossy" when it faithfully reproduces the encoder input,
> exactly?
> .."
>
> That is not the consideration here.

Of course it's not, because if it was, it would just prove my point
that you are basically acting like a nitwit.

> We **can** blame the encoder-decoder (combination) when the output is
> not equivalent to the input.

The input to a GIF encoder is exactly decoded by the decoder. You show
otherwise and I'll show you a defective encoder or decoder or both.

> In such a case ... the transmission method / media / file format
> is **lossy**.

If, as you aver, we must include prior processing steps as part of the
"encoder", then basically everything is "lossy". 16b->8b conversion is
necessarily lossy. Every filtering operation introduces noise, and are
thus non-invertible and "lossy". The entire processing chain from the
photons in free space at the scene to when they are re-instantiated by
the monitor introduces inevitable, and huge, losses.

By your stellar logic and reasoning, we must then conclude that
lossless TIFF files do not exist, that PNG is a flat lie, and that PPM
files are a scandalous conspiracy against truth.

And just ignore that that guy over there saying that you can separately
GIF encode each 8-bit channel of a multi-channel image. He's just
plain nuts or something, since such things are impossible: one is
forced, by some quirk of nature, to palletize the image to 256 entries.
Some sort macroscopic quantum exclusion principle at work or
something.

In conclusion, I can only say: wow! What an incredible concept you've
invented! How can all those signal-processing engineers have been so
deluded, and for so long? Thankfully, the mistake isn't too bad at
this time: there are only 1,267 (or something) textbooks that need to
be re-written. The 2005 Save The Children From Inappropriate Signal
Processing Definitions Act will fix this and many other problems.

Archived from groups: rec.photo.digital (More info?)

On Tue, 18 Jan 2005 21:54:56 +0000, Stu Dapples wrote:


> "Gautam Majumdar" <gmajumdar@XSPAMfreeuk.com> wrote in message
> news:wneHd.167146$48.78964@fe1.news.blueyonder.co.uk...
>> Gary, Thanks for the tips. My D-rebel saves in jpeg. I know I can save
>> them in raw but if I save them in default jpeg, is it OK to convert
>> them first to something like GIF, do the editing & then convert back to
>> jpeg
>
> GIF??? This is an attempt at humour right?

Right. Have a laugh at the old fool just entering the digital imaging
world :-).

From my limited reading I understood that GIF is a compressed but lossless
format. As a primarily linux user I try to stay away from the proprietary
formats as few of the opensource software can handle them. GIF, TIFF, JPEG
are all usable with opensource software but such software are often unable
to handle the proprietary file formats, such as PSD, PSP, etc.

I now understand that GIF is a lossy format in the sense that it loses
colour depth.

--

Gautam Majumdar

Please send e-mails to gmajumdar@freeuk.com

Archived from groups: rec.photo.digital (More info?)

You are obviously missing the English language definition of "loss."

You are also obviously now behaving in the manner characteristic of a
sub-teen-age troll.

This ends my participation in any discussion(s) with eawckyegcy@yahoo.com

Archived from groups: rec.photo.digital (More info?)

Confused wrote:

> On 18 Jan 2005 07:52:34 -0800
> In message <1106063554.499065.72990@f14g2000cwb.googlegroups.com>
> gary_hendricks@digital-music-guide.com wrote:
>
>
>><snip>
>>1. Edit in Lossless Format
>><snip>
>
>
> Good grief. One does NOT edit in "Lossless Format". By sheer logic
> and common sense, ANY editing is going to cause something to be lost
> from the original.
>
> BUT THAT'S NOT THE POINT
>
> "Lossless" and "Lossy" (or however the bloody heck it's spelt) are
> modern computer terms that define the integrity of a data compression
> method. If *any* single bit is modified in the data due to the
> compression method then it is LOSSY (which is a nice way of saying the
> data has been corrupted by the storage method).
>
> Sheesh... I'd be glad to kick off a File Management 101 thread if
> anyone is interested in basic concepts such as:
>
> "What's a file?" and "What's a path?"
>
> Jeff

.... but I type E N T E R and nothing ever happens

Archived from groups: rec.photo.digital (More info?)

On Wed, 19 Jan 2005 21:45:29 GMT
In message <ZxAHd.6968$IP6.6536@trnddc05>
"RSD99" <rsdwla.NOSPAM@gte.net> wrote:

> "Roger N. Clark" posted:
> > Gif is not a lossy format. It is a lossless compression format.
> > But it is limited to 256 colors, so it loses color accuracy
> > ..."

RSD99 commented:
> With all due respects ... you can't have it both ways.
> <SNIP>

"With all due respects" ... you can fool some of the fish some of the
time, you can fool most of the fish once in a while, but you cannot
fool the fish who pioneered technologies being discussed.

Jeff

Archived from groups: rec.photo.digital (More info?)

Bruce Graham wrote:
>
> But maybe Neat-Image works better *before* the image is manipulated,
> because then the noise reduction is done on an image which still looks
> like the noise profile??


That's what makes sense to me.

Archived from groups: rec.photo.digital (More info?)

paul wrote:

> Roger N. Clark (change username to rnclark) wrote:
>
>>
>> Finally, for contrast stretching, only use levels and curves
>> tools (in photoshop); others are additive tools and have
>> undesirable side effects. Levels and curves are multiplicative
>> tools. (at least in photoshop)
>
>
>
> Can you explain additive vs multiplicative?

Consider a brightening tool that is additive. Say your highest DN
is 245 and you want it to be 255. An additive tool adds 10
to all pixels, but that means your blacks at 0 then become 10.
You really want all pixels multiplied by 255/245 = 1.041,
so then 0 still comes out zero.

> My experience (might be mistaken, corrections welcome) for contrast
> adjustment:
>
> Levels cut off ends of a histogram rather crudely then stretches the
> remainder to fill.

Not if you limit the adjustments to the minima and maxima in the
data. Also (I think I said this in a recent thread), do the
adjustments in 16-bit mode so you have little to no loss
in precision.

> Straight lines in a curve adjustment are basically like levels or
> brighness/contrast.

Only for the middle slider in the levels tool.

> Curvy curves let you reduce the unused end of the
> range without eliminating it like levels. Put an eyedropper on the part
> of the image you want to increase contrast for & see where is lays on
> the curve then bend so it is steeper in that range. Curves let you do
> things like lighten the shadows without burning out the sky in one
> smooth transition. Curves for contrast increase boost saturation so you
> might need to adjust then it ends up losing some of the initial richness.

Yes, that is why I say use the levels tool to adjust the
brightest and darkest parts of the image (I rarely
use the middle slider), then I switch to the curves tool.
>
> Manually masking as a burn & dodge exercise can work well but is very
> difficult to transition or manually mask the skyline edge. I often can
> get great results erasing out with a large soft brush though sometimes
> it looks awful. Any of these other techniques can be masked out & really
> that's more precise than trying to get one curve to do everything if
> it's possible to mask tastefully. Masking can produce an unnatural
> lighting effect.

Yes. Learn to feather the edges of a mask.

> Shadow/Highlight 'adjustment' (filter actually) in PS seems rather crude
> for decreasing contrast.

It isn't exactly decreasing contrast, as it is on a large scale
compressing dynamic range, leaving local contrast relatively
unchanged.
>
> An interesting alternative technique is to duplicate the image on a
> layer, desaturate to B&W, invert to a negative & make it overlay type.
> This improves shadow detail and brings back tone to nearly blown
> highlights. Usually it looks best to cut back the opacity so it doesn't
> look too 'pasty'. It gives a more saturated image without the dayglow
> effect, sort of like subtracting the black, then you can increase
> contrast without blowing out shadows & highlights if desired. If curves
> are used to increase contrast then hue normalized, there is less color
> remaining but this step adds back the color to the process.

OK, but I find such steps have too many side effects.
I prefer feathered regions then using the curves tool and
shadow/highlight (but I use curves more).

> A simpler thing to try is duplicating a layer & making it either overlay
> or screen to lighten or darken/increase contrast. Sometimes it works
> sometimes it doesn't.
>
> The Color Balance adjustment seems the best place to adjust hue white
> balance issues if white balance/RAW isn't enough, you've got RG&B all on
> sliders, doing individual RGB curves is just too difficult to assess
> unless you had some magic knowledge of what's needed, the color balance
> sliders are all on one tool.

The photoshop color balance tool seems to be an additive
tool so I use it sparingly.

> Displaying the histogram tab is helpful to see what's happening in
> another level of abstraction. I wish I understood the histograms better,
> they do definitely tell a story but it's hard to convert to common
> sense. Breeze Browser has RGB also charted on the histogram which is
> interesting sometimes they are way off & sometimes all together. I don't
> know if that means you should try to get them to match or some pictures
> just naturally have more red in the highlights for example.

There is no one histogram shape that is universally best for
all images and all colors. For example, consider a sunset.
>
> Sometimes I get too carried away trying all these & end up with a mess
> when I come back the next day to see what I've done. That's a good way
> to learn though I suppose.

Yes.

Roger
photos at: http://www.clarkvision.com

Archived from groups: rec.photo.digital (More info?)

Kibo informs me that Gautam Majumdar <gmajumdar@XSPAMfreeuk.com> stated
that:

>Right. Have a laugh at the old fool just entering the digital imaging
>world :-).
>
>From my limited reading I understood that GIF is a compressed but lossless
>format. As a primarily linux user I try to stay away from the proprietary
>formats as few of the opensource software can handle them. GIF, TIFF, JPEG
>are all usable with opensource software but such software are often unable
>to handle the proprietary file formats, such as PSD, PSP, etc.
>
>I now understand that GIF is a lossy format in the sense that it loses
>colour depth.

Under Linux, .PNG is a much more useful format than the others you've
mentioned, as it's lossless (by default - you can make it palletised,
etc).

--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------

Archived from groups: rec.photo.digital (More info?)

David J Taylor wrote:
> usenet@imagenoir.com wrote:
> []
>
>>Under Linux, .PNG is a much more useful format than the others you've
>>mentioned, as it's lossless (by default - you can make it palletised,
>>etc).
>
>
> It's often my preferred format under Windows as well - the lossless
> compression is tailored towards images making the file size a little
> smaller.

Yeah, I tried PNG for the first time with these results:

2.3MB JPG (95% quality) 8-bit sRGB
5.5MB RAW Nikon D70 aRGB NEF
7.4MB 8-bit sRGB PNG
24.5MB 16-bit aRGB PNG
35MB 16-bit TIFF
90MB PSD with a couple adjustment layers & one duplicate layer

I just have a cheapo Epson C80 printer now and I can't see how to
specify adobeRGB for it so converted to sRGB after working the
adjustments to bring out shadows, adjust WB, chromatic aberrance
correction, color noise reduction, sharpening, etc. I printed from PSD &
the 8-bit sRGB PNG & could not tell the difference. Irfanview did
display the colors noticeably different for all these, not true to the
photoshop original which is a bit disturbing but I did get a bit carried
away with this test, boosting the saturation may have been pushing the
gamut but that's good for a test. Irfanview also stripped them down to
8-bit sRGB without a proper color space conversion which messed up the
colors.

When I get a better printer, I'll also get a monitor calibration spider
& readjust any pics I feel are worthy of printing so there is no real
use in saving the PSD with curve layers at that huge of a size. I'm
working on a laptop as a desktop replacement so HD space is limited
without needing an external drive I want final versions on the main
drive of all good pics. And for now I can't tell the difference between
16-bit aRGB & 8-bit sRGB so the 8-bit PNG at just a bit bigger than the
RAW makes sense.

It does make sense to shoot RAW adobeRGB and make adjustments even if
saving down to jpeg for web is my main current use doing the adjustments
with the best original is where that extra info is most important. Once
the adjustments are made though, it's all clearly visible in 8-bit sRGB
& the difference is going to be very subtle.