Closed Beep6581 closed 9 years ago
Hi Ingo, I recall looking at that portion on code. The USM sharpening is on the L channel.
After resizing, image is in RGB format. I thought converting resized imaged to Lab,
sharpen there and convert back to RGB. The output sharpening would still not be visible
in preview. The control can be the same as for USM.
What do you think?
Reported by michaelezra000
on 2013-09-16 03:40:52
Hi Michael, that's a way it could work, but it would be nice to also have RL-sharpening
available in this step, because it gives very good results with downsized pictures.
For me there is no need to preview this step, because I always use the same settings.
To identify the right values you can save to TIFF and try with TIFF. Afterwards apply
this settings to a bunch of pics and put them into the queue.
Ingo
Reported by heckflosse@i-weyrich.de
on 2013-09-16 10:22:13
Generalizing the problem, we need to decide where to place the UI elements that relate
to the Output. Essentially these are the post-resize functions. Eventually, these tasks
may expand to include sharpening, borders, frames, watermarks, etc. Does this deserve
a separate Tab (E.g. after Metadata)?
Another placement could be in the 'Fast Export" tab, that is visible in the FileBrowser
only.
Reported by michaelezra000
on 2013-09-16 13:18:20
Re #3:
Even more generallizing the problem, we could think about the user's workflow, e.g.
:
== A ==
1:1 scale image generated by RT, with automatic derived images for the web, done by
Gimp, IrfanView (in my case) or any other light and fast tool that can add sharpening
and even a signature without touching the original 1:1 image.
Problem: ICC color profile handling depending on the target...
== B ==
Directly generating the web image out of RT, with all the added features (post resize
sharpening, signature, etc).
Problem: One image processing is needed per target, which can be very time consuming,
and a post resize sharpening tool would be necessary.
One possible solution: adding a "target" concept to the output panel, with this kind
of pipeline:
** Original image **
|
V
simpleprocess
-------------
load the image and store it in a floatimage
|
V
simpleprocess_ (saveMe=false)
--------------
process the floatimage with
the sidecar pp3 (1)
|
V
** Intermediary image **
|
------------------------------------------------------- - - -
| | |
V V V
simpleprocess_ simpleprocess_ simpleprocess_ <- (saveMe=true)
-------------- -------------- --------------
with with with
"full size.pp3" "web.pp3" "print.pp3"
(2) (2) (2)
| | |
V V V
Save to Save to Save to
location #1 location #2 location #3
Each of this four pp3 would be plain ProcParams, it'd be up to the user to use partial
profile where appropriated. So one could set sharpening and resize in (1) and handle
ICC color conversion in (2) as well a possibly second sharpening.
If we use this mechanism, the sharpening would need to be moved to the end of the pipeline,
after the resize and before the color conversion. We then have to find a way to correct
sharpening values based on resizing factor to somewhat ensure backward compatibility.
About the GUI:
--------------
In the queue tab, the output directory and file format would be replaced by a target
list with checkboxs to activate them. When clicking on an add ("+") button, a window
would popup to select a partial procparams, an output directory (or the path template,
of course) and a file format, and name that target (almost all the code for this part
already exist). I think that the Export panel could even be replaced by a dedicated
target.
In simpleprocess, the generated image (pre or post color conversion, i don't know)
actually stored in buffers would then be reprocessed in the newly created "simpleprocess_"
method as much times as there are activated target, each target saving the image to
its own location.
About the new Tab:
------------------
A agree that a new tab should be created for decorations, but it could then wait for
the real tool since the post resize sharpening wouldn't be necessary anymore.
-----
On a side note, the Type of this issue has been set to Type-Roadmap; was it intentional?
This type is reserved to discussion around what to incorporate in future versions.
So I've set it to Type-Enhancement.
Reported by natureh.510
on 2013-09-17 21:02:59
Hombre, I set it to Type-Roadmap because I thought we should discuss this for a future
version. I also have a workaround for Web-Images (Process without sharpening in RT
to TIFF => resize with ImageMagic => load the TIFF in RT => RL-sharpening => Save as
JPG
So, for me, it was no need to hurry and I put it to the Roadmap.
Ingo
Reported by heckflosse@i-weyrich.de
on 2013-09-17 21:12:36
Hombre, my imagination of Output-sharpening is exactly the same as #4 of Issue 1358.
Just an additional blind (without preview) step after resizing the picture.
Ingo
Reported by heckflosse@i-weyrich.de
on 2013-09-17 21:23:36
We already have a process "output" is "output gamma." This process essentially allows
editing images (TIFF, JPEG from RAW or others), which will be seen in software without
color management (eg: Firefox ...)to restore a correct apparent gamma.
Reported by jdesmis
on 2013-09-18 06:49:18
Another use of "output gamma" seems more confidential, but essential for professional
printing CMYK (CMJN in french)...
Acting on output gamma,Lab values are not (or little) change, but the RGB values
are changed a lot , so the CMYK values...
Reported by jdesmis
on 2013-09-18 09:26:44
Re #7:
Output gamma let us chose which gamma to use at the very last step of the pipeline,
but it's not a reprocessing of the image with a full procparams set.
Re #6:
Yes, the easiest way of adding post resize sharpening would be to add that new "Post-resize
Sharpening" tool, but we might need to think about my idea (comment #4) one day. Abobe
already let use change some parameters (including sharpening) in the Export window
(IIRC) depending on the target. But with Targets implemented in RT, the CIECam would
also take all its meaning: correction depending on visualization conditions. So your
print target with white surrounding will have different values that the web target
with possibly black surrounding. Ok, i just defend my idea here :P
I don't mind going with your solutions, but please think about the user's experience
and workflow. To be honest, i've thought about the Targets by the time of the Fast
export commit (i should have explained it earlier but didn't saw the Fast Export issue
:-/ ).
Reported by natureh.510
on 2013-09-18 09:46:24
Excuse my bad english, I'm not sure all understand (in the deepest sense of the term
!).
If I spoke of "output gamma" is that it is a terminal treatment, and we do not see
in the "preview" the result ... So, by assimilation ...
I agree with Hombre for CIECAM ...
For "Ouput shrapening" I think we can program a "sharpening" at the end of treatment
and in RGB mode (may be it is not feasible?)
:)
Reported by jdesmis
on 2013-09-18 10:29:21
Hombre, as said, I don't need the output sharpening in RT, but I would be glad to have
it in a future version. I'm working with RT since RT 2.4, so there's no need to hurry.
I originally labeled the Issue as Roadmap 4.3. Your B-way looks very good but also
sounds to be a lot of work. In my opinion there's no need for a hasty reaction. The
better way is to discuss (your b-way is a good base) and get a good solution!
Ingo
Reported by heckflosse@i-weyrich.de
on 2013-09-18 22:17:23
Okay, I'll concentrate on other features, but i don't think that the b-way will be that
complex to do.
Reported by natureh.510
on 2013-09-18 23:28:21
Reported by entertheyoni
on 2013-11-10 18:50:41
Duplicate
Reported by michaelezra000
on 2013-11-10 18:54:14
Originally reported on Google Code with ID 1975
Reported by
heckflosse@i-weyrich.de
on 2013-09-15 22:41:33