Preview looks different to saved image at 100%

[Beep6581]

Originally reported on Google Code with ID 2866

I ran into this issue yesterday, blamed it on lack of sleep, but now I've been reproducing
it again and can't solve it, so it must be a (recently introduced?) bug: this photo,
even when you use neutral at 100% zoom, just looks very different to the saved image.
Look at the highlights on the dorsal side of the musician's hand, on his forehead and
even on his shirt color, let alone the accordion color.
http://rawtherapee.com/shared/test_images/pentax_k10d_accordion.dng

It's a serious issue for me as I'm supposed to be delivering these shots today...

Reported by entertheyoni on 2015-08-03 12:25:19

[Beep6581]

When I select any one of the following, then the preview in RT matches the image in
Geeqie (both RT and Geeqie use my Eizo monitor profile, and Geeqie is set to use the
profile embedded in the image):
- set working profile to sRGB,
- or set output profile to RT_Large_anything, doesn't match with RT_Medium,
- or set output gamma to anything but default
- or enable free gamma

Reproduced in tip as well as in 4.2.226 (993483b90caf).

Surely the image should match when using sRGB output and when Geeqie is set to use
the embedded profile? And if that was incorrect (but I'm sure its correct), then surely
it should continue not matching when I use output gamma sRGB_g2.4_s12.92? But it does
match when I use output gamma=sRGB_g2.4_s12.92, and not when I use output profile=RT_sRGB

Example of no match:
http://i.imgur.com/K3bhqej.jpg
http://i.imgur.com/p1ybMdb.jpg

Example of match:
http://i.imgur.com/sIlUrcD.jpg
http://i.imgur.com/Uvjgkiy.jpg

Reported by entertheyoni on 2015-08-03 13:07:49

[Beep6581]

I don't know if this helps you track down the bug, but in my version shortly before
yours (4.2.222 instead of 4.2.226), preview and final output seem to match perfectly:
http://filebin.net/wi1hgtfuyb

Branch: default
Version: 4.2.222
Changeset: cb035234398c
Compiler: gcc 4.9.2
Processor: generic x86
System: Windows
Bit depth: 64 bits
Gtkmm: V2.22.0
Build type: Release
Build flags: -m64 -mwin32 -mthreads -msse -msse2 -mtune=generic -fopenmp -Werror=unknown-pragmas
-mwindows -DNDEBUG -O3 -Wno-aggressive-loop-optimizations
Link flags: -mwin32 -mthreads -static-libgcc  -mtune=generic -mwindows -s -O3
OpenMP support: ON
MMAP support: ON

Reported by stefan.ittner on 2015-08-03 18:08:12

[Beep6581]

From the saturated colors in the screenshot I take it you compared them on a non-wide-gamut
monitor?

Reported by entertheyoni on 2015-08-03 19:23:30

[Beep6581]

It's a wide-gamut monitor (Dell U2311H), but I use it in sRGB mode. Maybe I misunderstood
your problem, but I thought you were also talking about sRGB output(?). Do you want
me to test any other configuration?

Reported by stefan.ittner on 2015-08-03 19:34:59

[Beep6581]

Same problem with cb035234398c 4.2.222.

I have RT set up to use the Eizo monitor ICC. When I export the image using neutral
settings and then open the resulting TIFF in RT (or in Geeqie, an external image viewer),
the colors clearly differ from those I see when I look at the raw preview.
When I set RT to use my laptop monitor profile, the raw and TIFF match. Why?

DNG, Eizo monitor profile http://i.imgur.com/4GjiNp5.jpg
TIFF, Eizo monitor profile http://i.imgur.com/oNKI8cM.jpg
DNG, laptop monitor profile http://i.imgur.com/hjRDnVj.jpg
TIFF, laptop monitor profile http://i.imgur.com/uhcxVRC.jpg

Reported by entertheyoni on 2015-08-03 19:36:51

[Beep6581]

Please try it in your profiled wide-gamut mode.

When using neutral settings, the output profile is set to RT_sRGB, this is embedded
in the TIFF so it should look identical to RT's preview when viewed in a color-managed
image viewer, or in RT itself. Right? Or have I lost it?

Reported by entertheyoni on 2015-08-03 20:03:13

[Beep6581]

There was an issue regarding discrepancy of handling raw images and non raw. Please
upgrade to the latest version which contains the fix.

Reported by michaelezra000 on 2015-08-03 20:27:07

[Beep6581]

You are right, I can reproduce with monitor set to AdobeRGB (and also Windows monitor
profile set to AdobeRGB). Tiff is displayed with Irfanview with color management activvated:
http://filebin.net/ojr8kxpmni 
Also when the TIFF is opened in RT, it matches the TIFF in Irfanview, but not the Raw
file in RT.

Reported by stefan.ittner on 2015-08-03 20:29:30

[Beep6581]

Bare with me. 

RawPedia says, "The preview uses the working color space but does not take into account
the output profile or output gamma."

I want to work on my image on my Eizo. I calibrated it using its built-in colorimeter
in its wide gamut color space (covers 99% of AdobeRGB), then got the resulting monitor
ICC and I use it in RT and in my image viewer. I want to use ProPhoto as the working
space in RT so I control what happens with saturated colors instead of having them
clipped or color resolution lost outside of my control, then I want to save the image
using an output space of RT_sRGB to JPG so it looks decent on most devices. Of course
I want the preview to match the saved image when both are viewed in color-managed programs
(or when both are viewed in the same program - RT). Is this an unrealistic expectation?
I thought this worked all along, as colors matched before. Now they don't.

Reported by entertheyoni on 2015-08-03 20:33:51

[Beep6581]

Michael: I always report on tip, but I also tested on some random old version before
the DCP changed to exclude those. Currently testing and reproducing on RawTherapee-4.2.270
3128:cf34cf45d42d

Reported by entertheyoni on 2015-08-03 20:35:37

[Beep6581]

Some Rawpedia quotes:
(1) "The preview uses the working color space but does not take into account the output
profile or output gamma."
(2) "The image preview will always show all colors the display is capable of though,
which may be more or less than the selected output profile if the monitor profile has
been configured in Preferences."

(1) seems wrong because the preview as such does not use the working color space at
all but apparently the monitor profile, as (2) suggests. Of course the chosen working
profile may influence the preview output, but the output is still displayed in the
monitor profile (and not ProPhoto, as the quote suggests)

As regards (2), it is questionable if this behaviour is desirable. Why does the preview
show colors that may or may not be present in the final output?  

IMO preview should always try to match the final output as closely as possible, anything
else seems like madness to me :)

Reported by stefan.ittner on 2015-08-04 06:41:25

[Beep6581]

Madness! Yes, that's what it feels like :)

Michael, Anders, as far as I know you've been using wide-gamut displays with RT for
a long time, while I'm new to the game. Could you comment whether my expectation is
currently possible?

Reported by entertheyoni on 2015-08-04 07:01:00

[Beep6581]

Yes I've used a wide gamut monitor for a long time.

If I remember correctly the screen shows the "actual image" as good as it can, which
means working profile converted to monitor output profile. I think this is how most
raw converter software works, including the commercial ones like Lightroom.

The output profile in most commercial software is generally not chosen until export,
so the software does not really know what the output will be. There are typically specific
soft proof modes though.

This is different with RT where the output profile is always there, so we could filter
it through the output profile first before going through the monitor profile. A long
time ago this was discussed and ended up in issue 2062 which has not been implemented.

I'd suggest some sort of proofing mode drop down selection, (which should not be a
part of the pp3). RT works now per default as most other software do, but it lacks
proofing modes. The first to add would be to be able to filter through the output profile.

Reported by torger@ludd.ltu.se on 2015-08-04 09:03:18

[Beep6581]

Anders how would you suggest I proceed for the time being? I have a wide-gamut monitor,
I'd like to use it in wide-gamut mode, and I want the profile converted to sRGB at
the end so it looks as it should on normal displays.

Reported by entertheyoni on 2015-08-04 11:51:50

[Beep6581]

Hello

I have to be hospitalized ... which prevented me to provide information regarding this
issue.

I think there is misunderstanding on the role of "output gamma" ... and the difference
between "preview" and "output"

My english is very bad and I am not sure to understand what you want exactely ?

But there is a section of Rawpedia where I explain :

In french (I am sure of the text) :
http://50.87.144.65/~rt/w/index.php?title=Color_Management_addon/fr
==>espace de sortie "output profile"
or in english : "Color management addon" 

Furthermore color management is complex. You can not compare the "similarity" if the
color management engines are not the same (LCMS is different from Adobe)

More, on the same engine, Monitor Profile has no (or little) incidence in comparison.
Certainly according to the quality of this profile, images will be more or less beautiful,
but it will play little variance (unless the profile is completely "out")

If you have Photoshop, you can easily see the influence of "output profile / gamma"

I don't say there is no problem, because it is very complex...perhaps there is one,
but I want understand what ??

Reported by jdesmis on 2015-08-05 17:02:09

[Beep6581]

#14: personally I haven't really felt that strong need for any proofing mode despite
my wide gamut. Gamut mismatch only happens for very saturated colors, and you see in
the histogram and clip indicators (which does show output profile result) if you have
clipping or not.

One idea could be to always filter the preview through the output profile before the
monitor profile, in a way that would be more logical although different from how others
do it. It's probably a trivial change. Otherwise we should think more about soft-proofing
and how it should be presented in the GUI.

A simple dropdown with a few alternatives maybe "monitor profile - perceptual", "monitor
profile - relative colorimetric", "output profile - perceptual", "output profile relative
colorimetric". I'm not sure how we do gamut mapping now, maybe we always let LCMS do
relative colorimetric?

For me personally I probably would prefer to work with monitor profile - relative colorimetric
most of the time, that is how it's now (I think), despite that I most of the time render
for sRGB. This way I can see on screen how saturated colors really are, and then by
reducing saturation etc to remove clip indicators I see how much I loose. If I have
no clip indicators the output should match.

That is I'd prefer some sort of dropdown so you can select viewing mode.

Reported by torger@ludd.ltu.se on 2015-08-05 19:09:00

[Beep6581]

I'm still not clear on what the recommended procedure is when I have a wide-gamut monitor,
I want to make use of my wide-gamut monitor, I shoot LED-lit concerts, and I want the
end result to be viewed and look good in sRGB.

To filter the preview through the output profile before the monitor profile, could
you provide a tiny patch so I can test it out? It can be hard-coded for now, we can
decide whether to add it and make it optional via the GUI later, if it solves the problem.

"Gamut mismatch only happens for very saturated colors, and you see in the histogram
and clip indicators (which does show output profile result) if you have clipping or
not."
Please see the screenshots in comment #5 as they show huge mismatch.
There is a chromaticity histogram in RT, but it shows no clipping for this image, nor
does it change when I toggle "Use working profile for main histogram and Navigator"
and reload the raw. Should I open a bug report?
http://i.imgur.com/IfTdcmJ.png

The R, G and B histograms do change relative to that setting, but they seem to be of
no use in informing me how much to compress chroma in order for the image to look good/not
horribly clip in sRGB, because white = clipped red, clipped green, clipped blue. http://i.imgur.com/etgjDJg.png
If there is a way to use them, I'd be grateful if you could explain. But I feel they
are the wrong tool for the job - the chromaticity histogram would be better, though
it too would need to individually show red, green and blue chroma. So maybe the only
option for now (until we can pipe the preview through the output space) is to use sRGB
as the working profile? Are there any other options?

Reported by entertheyoni on 2015-08-05 21:30:16

[Beep6581]

Switching the working space is a decent shortcut, especially while observing the histogram.
Overall... i personally dont worry too much about the sRGB aspect, while using wide
gamut monitor for editing. The reason is that usually majority of devices used for
viewing don't cover full sRGB anyway so whats the point tryinv to make it look best
at sRGB when it image wiil be viewed at 70% sRGB? For web images I simply rely on blind
relative colorimetric conversion for 99% of cases.

Printing, however, is a different story and this is where output space proofing may
be actually useful as it is specific to the profile which is specific to the actual
capabilities of the printinv setup (not the hopeful sRGB monitor capabilities). Even
then, its only part of story as rarely printer icc profiles are specific to the viewing
condition at which print will be observed, so in that case it is still a sbot in the
dark, unless viewing conditions match icc profile expected illuminant.

So in my view proofing is a valuable feature with a more practical usecase of print
preparation. Still, i could never make sence of the proofing in photoshop it just was
not helpful whatsoever. A better preview was after actual conversion to output profile.
P.S. Sorry for late reply.

Reported by michaelezra000 on 2015-08-06 01:55:39

[Beep6581]

#17 I need to have a look at your test image and see what's happening. I'm not at a
wide gamut workstation for the moment, but at an old laptop with a useless TN screen.
I mostly work with landscapes which might mask some of the issues.

The conversion to monitor is made in iplab2rgb.cc/lab2monitorRgb, and the transform
for it is created in improcfun.cc/firstAnalysis

I'm a bit rusty on LCMS2 transforms but maybe one can hardcode something in firstAnalysis
and create a transform that also includes the output profile.

Reported by torger@ludd.ltu.se on 2015-08-06 07:47:22

[Beep6581]

I'll make a patch for you in a few tens of minutes, but I have no ability to test it
now.

Reported by torger@ludd.ltu.se on 2015-08-06 07:56:42

[Beep6581]

Here you have something to play with. I haven't been able to test it. I haven't checked
when firstAnalysis is called, for example if it will be re-called when you change output
profile, otherwise it will keep the old transforms...

Reported by torger@ludd.ltu.se on 2015-08-06 08:21:08

---

• Attachment: monitor-patch.txt

[Beep6581]

I tested the patch, but I see no difference (I change many time output profile)... what
should we do?

I still do not understand what you want!

To control the gamut in 95% the excess of the RGB gamut is due to negative values RGB.
This can be seen on the left side of the histogram. and in 5% to positive values >
65535 (rare)..on the right side.

If that is what you are looking for, in a first step, we can put something simple,
by replacing the checbox "avoid color shift" (Lab adjustements), with a combo box,
with choices such as: none, working profile, output profile...

Obviously "soft proofing" would be better, but imposes an action factor (gamut, contrast,
etc.), and wille complex to implement

:)

Reported by jdesmis on 2015-08-06 11:49:44

[Beep6581]

I haven't been able to test my own patch in #21 so I don't really know if it actually
works, but the intention is as follows:

Say we have a wide gamut monitor, which can roughly display AdobeRGB, and we have an
image with very saturated colors, and we want to make an sRGB output. Let's keep working
profile at ProPhoto so it's not limiting.

Without the patch the image you see on your monitor will be what the monitor can show,
that is roughly AdobeRGB, despite that we have sRGB as output profile. This means that
some super-saturated colors you can see on your AdobeRGB-capabale screen will be clipped
in the sRGB output file and the clipped result can be a different color.

With the patch in #21, which I don't know if it works, is supposed to filter through
the output profile, sRGB, before it's sent to the monitor, that is those super-saturated
colors will then be clipped. This means that you then will see the same output as what
will hit the disk when you export.

However if we look at an image with normal saturation colors, so it fits within sRGB,
then there will be no difference of course.

Reported by torger@ludd.ltu.se on 2015-08-06 12:52:14

[Beep6581]

I just got a chance to test on a wide gamut monitor. The patch in #21 works, but it
won't change rendering when you change output profile before you have closed and opened
the file again.

If you change output profile, close the image, and open it again the render will then
match the output. This can be seen on the red on the accordion image. Try RT_sRGB output
and then RT_Large_sRGB output.

Reported by torger@ludd.ltu.se on 2015-08-06 13:03:05

[Beep6581]

When saving to output there will today be a gamut mapping from Lab to output space (usually
sRGB) in iplab2rgb.cc/lab2rgb16, using the colorimetric intent set in preferences,
usually relative colorimetric. The Lab image is based on the working space of course,
which usually is ProPhoto.

When viewing preview on screen there's a gamut mapping from the same Lab to monitor
space, using the same colorimetric setting from preferences.

Suggestion for a changed behavior that doesn't require that much work:

 *) the colorimetric intent for the gamut mapping to output profile should be a pp3

    setting, rather than using the preferences setting, alternatively hard-code it
    to relative colorimetric.
 *) the colorimetric intent for the monitor is the one in preferences, and only used

    for the monitor.
 *) before sending to the monitor profile, always pipe through the output profile,
    that is first do the same output profile processing as when saving to file, and
    then send that output to the monitor using the monitor profile and the rendering
    intent set in preferences.

This means that if you have set to sRGB output have a wide gamut monitor and want to
see what the color is before clipping to sRGB you need to temporarily change output
profile to one larger than the monitor (eg RT_Large_sRGB)

Reported by torger@ludd.ltu.se on 2015-08-06 13:25:55

[Beep6581]

Concerning rendering intent, what about this issue? https://code.google.com/p/rawtherapee/issues/detail?id=2763
(includes examples)
I couldn't see any visible difference at all when trying all the rendering intents
in the option menu, why is this so?

Reported by stefan.ittner on 2015-08-06 13:32:30

[Beep6581]

For the sake of performance I woild prefer the output profile conversion be optional.
This is related to viewing perspective, not editing, so it can belong to a toggle button
in the editor toolbar.

Reported by michaelezra000 on 2015-08-06 13:40:03

[Beep6581]

#26: I think we could remove the rendering intent setting and hard-code to relative
colorimetric everywhere. I don't feel the rendering intent selection makes much sense
except for printing, and we don't do printing yet.

With LCMS, and any other commercial color management system, relative colorimetric
is still not hard-clip but has some perceptual rolloff. The only engine I know of that
really do hard-clip at relative colorimetric is Argyll.

This means that in many cases relative colorimetric looks virtually exactly the same
as perceptual. I'm a bit rusty on how perceptual works, but it could even be the case
that it is exactly as relative colorimetric if the ICC profile doesn't have some special
perceptual table built in, and as far as I know it usually is only printer profiles
that have that.

The rendering intent is about gamut mapping, how to convert too saturated colors to
fit within a smaller gamut. You can only see an effect of the rendering intent if your
image has more saturated colors than can be presented in the output.

Reported by torger@ludd.ltu.se on 2015-08-06 14:17:02

[Beep6581]

There are some cases in the code when LittleCMS is bypassed, the whole stuff with the
free gamma output etc is things I don't understand, so I'm not really comfortable with
making a patch that would work in all cases.

It seems to me that when the original design was made the gamut mapping issue was not
really considered, so the way it is now is just the way it happened to become. It's
not until you have a wide gamut screen and work with extreme saturation colors these
things can become visible.

#27: yes the extra conversion will hurt performance, not sure by how much though. We
could test and see if it's relevant. I don't mind having a toggle button though, but
I really *hate* making changes to the GUI, it seems that the most trivial thing takes
hours for me, and still leaving bugs...

Reported by torger@ludd.ltu.se on 2015-08-06 14:24:57

[Beep6581]

Concerning performance, the current Lab to Monitor conversion is made in double precision
(64 bit floats) to 8 bit integer, I don't really understand why the upsampling to 64
bit float is made when the output for the monitor is 8 bit integer. Resampling from
the internal 32 bit float to 16 bit integer before making a conversion to 8 bit integer
seems to me to make more sense, but there might be some reason behind it...?

Reported by torger@ludd.ltu.se on 2015-08-06 14:28:52

[Beep6581]

I think there is a risk that it will be hard to make anything happen concerning this
issue as I'm not sure if any of us current developers have full view of the intentions
of the original design.

Issues similar to this has been discussed several times before and they just fade away
with no action. Lots of discussions, very little or no coding :-\

Updated suggestion from #25

*) Remove the rendering intent setting from preferences, and hard-code relative 
   colorimetric everywhere, as there's no real value with perceptual rendering 
   intent except for printing.
*) Always filter through output profile before sending to monitor. Test for 
   performance, change current double->8 bit conversion to an integer conversion. 
   Hopefully dual integer conversions won't be much worse than the old, and then
   we don't need a toggle button
*) Open issue: how to deal with the current LCMS bypass cases, maybe just duplicate
   the code into the lab2monitor conversion function in some way...

Reported by torger@ludd.ltu.se on 2015-08-06 14:52:11

[Beep6581]

Yes, upsampling to 64 bit float sounds to make no sense. But why do you want to convert
from 32 bit float to 16 bit integer and then to 8 bit integer? Why not convert directly
from TYPE_Lab_FLT to TYPE_RGB_8?

Ingo

Reported by heckflosse@i-weyrich.de on 2015-08-06 15:03:52

[Beep6581]

Anders, ignore my question. I looked at the unpatched code...

Reported by heckflosse@i-weyrich.de on 2015-08-06 15:07:19

[Beep6581]

Jacques I'm sorry to hear about your hospitalization - I hope you're recovering well!
You asked for a better explanation of what I want - Anders explained it well in comment
#23

Anders the patch seems to work well for me!
Without it, I ended up with "org" which looks horrible on ~70% sRGB (my laptop). With
it, I was able to get "3" http://filebin.net/s41kn2fgz0/

Let's get this patch into RT. I can help with the GUI part.

If there will be a button for it, I would put it in a toolbar in the Editor.
Maybe the "Use working profile for main histogram and Navigator" option should be combined
with this "Use output profile for preview" option?

Reported by entertheyoni on 2015-08-06 15:33:19

[Beep6581]

Ok, I'll post a refined patch soon.

Reported by torger@ludd.ltu.se on 2015-08-06 16:19:39

[Beep6581]

Here's an improved patch, now it works on the fly. What the patch does:

- Hardcodes relative colorimetric everywhere (rendering intent setting is hereby 
  dead, no use to have setting that makes no meaningful/visible difference)
- Hardcodes filtering through output profile before going through monitor profile
- Todo: haven't actually removed the rendering intent setting from the GUI
- Going through the output profile will only happen if there actually is a configured
  monitor profile, otherwise there's a direct sRGB conversion to the monitor. I
  think this is okay as it's not likely that anyone would export to a smaller space
  than sRGB.

I've heard littlecms is considerably slower for float conversion than integer, so one
could possibly experiment to make the float->float + float->int8 conversion to say
pre-truncate to 16 bit then 16->16 + 16->8 for performance, as we end up with 8 bit
anyway going to 16 bit integer sooner will probably not have any visible effect.

Reported by torger@ludd.ltu.se on 2015-08-06 16:52:10

---

• Attachment: monitor-patch-2.txt

[Beep6581]

Concerning function I'm fine with the #36 patch, I don't think we need a toggle button
from a usability standpoint, but maybe if there's some bad performance. I'd first look
at trying integer conversions though.

I'm having a bit less time to code now, so it would be great if someone else could
take the patch further. If we're happy with the function there's not much more to do,
just remove the rendering intent setting GUI element and possibly test performance.

Reported by torger@ludd.ltu.se on 2015-08-06 16:57:41

[Beep6581]

#34: I missed the "Use working profile for main histogram and Navigator" comment, yes
I think it's an excellent idea to connect the toggle thing to that. Added that to the
attached patch.

Reported by torger@ludd.ltu.se on 2015-08-06 17:06:06

---

• Attachment: monitor-patch-3.txt

[Beep6581]

While at it, removed the rendering intent setting too.

Now it should be functionally complete.

Reported by torger@ludd.ltu.se on 2015-08-06 17:09:51

---

• Attachment: monitor-patch-4.txt

[Beep6581]

Reported by torger@ludd.ltu.se on 2015-08-06 17:10:14

• Status changed: PatchSubmitted

[Beep6581]

Anders thank you for the patch, it works well here and lets me get good colors when
working on a wide-gamut screen with wide-gamut raws and saving to sRGB. Could you commit
ASAP?

Regarding the change to Github:
During the migration, I will run all RT .cc and .h files through astyle to mostly improve
formatting and readability. I was worried that uncommitted patches would then fail
to apply, but I tested using monitor-patch-4.txt and I can in fact make any patch survive
the change. Attached is this patch but including the astyle changes so that it would
apply to astyle'd RT source in github.

Reported by entertheyoni on 2015-08-09 21:50:46

---

• Attachment: 2866monitor4.txt

[Beep6581]

Committed in (I'll now test which keyword triggers the markdown) revision 91f67f0cb6760cc2703cfaeb698bd4fa12ee6064 revision 91f67f0 Revision: 91f67f0cb6760cc2703cfaeb698bd4fa12ee6064 Revision: 91f67f0 Revision 91f67f0cb6760cc2703cfaeb698bd4fa12ee6064 Revision 91f67f0 rev 91f67f0cb6760cc2703cfaeb698bd4fa12ee6064 rev 91f67f0

Anders, "Open issue: how to deal with the current LCMS bypass cases, maybe just duplicate the code into the lab2monitor conversion function in some way..." does still need to be done?

The option "Use working profile for main histogram and Navigator" is still in Preferences, has the way it works changed? Is the following correct? "When enabled, the histograms and navigator show color values in the working profile's color space. When disabled, they show color values in the output profile's color space. Whether a monitor profile is being used is irrelevant."

[Beep6581]

Maybe could be closed, but I would first like to learn the answers to the questions in the post above.