dpx:swap-samples not functioning in 1.3.35?
Swiss army knife of image processing
Brought to you by:
bfriesen
Menu
▾
▴
#628 dpx:swap-samples not functioning in 1.3.35?
New user to GM, so apoligizes if this is user error. I have a series of DPX images that have swapped Red and Blue channels (hardware recorded), so I was attempting to use GM to flip the channels. However, the "swap samples" define doesn't appear to be working. My command line is this:
gm mogrify -define dpx:swap-samples=true -output-directory ../gmconvert *.dpx
I've also tried setting it to false, but same result. The issue is with 12-bit DPX's, but I get the same result on 10-bit ones as well (no change). Using other DPX define variables works (like setting the packing method).
GM version 1.3.35 Q16 installed on macOS 10.14.6 using HomeBrew.
On Tue, 21 Apr 2020, Garrett wrote:
My initial thought is that that swap-samples is working great, but the
problem is that swap-samples is applied when the file is read, and
then again when the file is written. This would happen because
mogrify is both reading and writing. The end result would be no
effect.
Does it work ok if you just do
gm convert infile.dpx -define dpx:swap-samples=true outfile.dpx
?
If this works then a solution would be to add explicit swap-samples
options which only apply when reading, or writing.
Bob
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Yes, using the convert command instead of mogrify gives the expected result on a 10-bit DPX. It does not work on a 12-bit DPX, however, which is what I actually have an issue with; is there a reason this option is limited to 10-bit DPX's?
Just to clarify: when you mention adding explicit options on read or write only, do you mean that can be invoked from the command line currently with the proper instructions, or something that needs to be integrated in a future release of GM?
On Tue, 21 Apr 2020, Garrett wrote:
Actualy, yes. It is limited to packed sample types since sometimes
there was a difference in interpretation as to sample order in the
packed pixle.
Yes, I am talking about simple code additions.
However, there is yet hope since what you want to do can be handled
via the -recolor sub-command via a useful matrix. Here is an example
from the documentation regarding how a recolor matrix can be used to
swap channels:
As an example, an image wrongly in BGR channel order may be
converted to RGB using this matrix (blue->red, red->blue):
So try
-recolor '0 0 1 0 1 0 1 0 0'
and see what happens.
Bob
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Brilliant, hadn't thought about using the recolor command to accomplish the same thing; it does indeed work with mogrify on 12-bit DPX's, so I'm in business.
As far as the swap-sample modifier, it seems to be restricted to bit depth and not packing method. It worked with 10-bit DPX's in both packed and filled (A-style) packing, but would not work with 12-bit DPX's in either packing method.
For a little background, these are files generated from a digital recorder attached to a digital cinema camera. The recorder manufacturer provides software for transcoding the DPX files if necessary, but only directly from the recording media and not from files that have been transferred to storage drives/media, which is obviously not ideal. Intriguingly, for transcode they offer two versions of 12-bit DPX's (RGB): what they consider "legacy" is what every other software reads as "normal", and their normal version (which is what the recorder does natively) is what has the crossed red-blue channels to every other software. I suspect as you mention elsewhere this may have to do with vagaries and interpretation differences within the DPX specs. They only have one 10-bit RGB implementation, which works correctly.
On Tue, 21 Apr 2020, Garrett wrote:
I see. I did not conceive that there was also an ordering issue with
12/16-bits. It is certainly possible to implement this support.
Interestingly, when GraphicsMagick implemented DPX, 12-bit DPX was not
really a "thing" yet. When Panasonic implemented 12-bit DPX support
for its Genesis camera, it used GraphicsMagick as a reference point to
emulate.
DPX itself is great, but it suffers from an improperly written
specification. The original DPX specification was pretty clear (data
was always stored based on 32-bit words), but when the updated DPX 2
specification came out, it described the pixel representations
differently, primarily because the specification author did not think
like a programmer. In addition to this, FilmLight decided to
implement its 12/16-bit DPX similar to the way data is encoded for
TIFF (perhaps by design, or by accident) and since their scanner was a
major source of 12/16 bit content, they drove the actual format which
was used.
Bob
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
While it does not address your concern with 12-bit samples, I have added dpx:swap-samples-read and dpx:swap-samples-write define support to address the problem that the effect may be null if dpx:swap-samples is used in processing with a command like 'mogrify' which does both read and write.
The dpx:swap-samples define has always supported 10-bit DPX only and addresses a specific concern with 10-bit DPX. The documentation addresses this topic.
A workable solution has been provided so I am closing this issue.