Non-orthogonal axes

[mszlazak]

This may not be possible but I have curves plotted on non-orthogonal (log scale) axes. The y-axis is vertical but the x-axis is 45-degees (counter-clockwise) from horizontal. If this is not implemented then would you please consider this? Thanks.

[nbehrnd]

It is possible to transform coordinate systems into each other, and the rotation between them is one of them. Thus, in the big picture, your case consists both of the rotation to deskew the image in first place.

If there are only a few images, you may consider pre-processing the .png / .jpg in an editor like inkscape.

• load the file with the DPI resolution of this original file
• pressing the keys of Ctrl + Shift + M simultaneously like a chord on a piano opens the transformation panel; the third stub in this new menu is about skew / deskew.
• export the deskewed image (Ctrl + Shift + E) to a) define a new file name and the place to store the newly written file; then b) trigger the export of the .png (there is a separate button «Export» in this menu). Assuming your original file is a bitmap, /do not/ use the simple Save-as (Ctrl + Shift + S) routine, because this may yield a .png of lesser optical resolution than the original bitmap read. This avenue (File -> Save As) is more suitable if the input file was a vector-based file, e.g., a .svg.

If there is a large batch of files to process, one could consider either a) to run running inkscape with a script, without a GUI. Or b) to digitize the raw images as they are now (skewed) and to deskew the intermediate data offered by the digitizer by application of the Euler formulae to perform the above-mentioned rotation in the subsequent step. (After all, it is about vector algebra.)

[nbehrnd]

Well, outside GitHub I thought about a skewed grid like the one below:

(ad-hoc derived from the .svg on wikimedia)

so the above comment does not yet solve the issue.

[mszlazak]

Thanks!

[ankitrohatgi]

Hi, non-orthogonal axes should work out of the box. Did you try it?

[nbehrnd]

@ankitrohatgi I submitted my plot (the artificially skewed wikimedia net with the blue curve added) to the digitizer. Indeed -- in line with your comment -- the results by the program match well the values accessed by visual inspection. Contrary to my initial line of thoughts, a prior deskewing for this type of representation is not necessary. It looks like this operation is not necessary because the transformation applies simultaneously to the represented object, the blue curve, as well as to the coordinate system.

Still, I continue to think the plot shown by the OP conceptually is different from either a cartesian coordinate system, or one derived from a cartesian system by skewing. For me, the capacitance plot shown by the OP is more similar to the enthalpy / Mollier plot shown below. (No, not a typo; Richard Mollier is not the French writer Molière.)

(credit)

[nbehrnd]

In part in reply to @mszlazak's comment below, in part spurred by own interest.

The comment in question (April 17, 2021) reads:

«@ankitrohatgi

I have not tried it yet but like @nbehrnd I also realized that it was just an axis re-orientation and the curves were not skewed. I wonder why they bothered to do this in the first place! Thanks.»

By further reading, I come to the conclusion that the first diagram is not skewed (the red net in the illustration below); thus equations like the ones discussed e.g., here do not apply. Instead, because the traces about (0.5, 1, 2, 5, 10) µ are not straight lines, but curves, it is more likely that this plot falls into the category of curvilinear (the blue net):

(credit).

One of the answers about «What is the use of orthogonal curvilinear co-ordinate system?», although a bit tangential for being specific on orthogonal curvilinear coordinates on physics.stackexchange.com replies by

«Curvilinear coordinates are a coordinate system where the coordinate lines may be curved. A Cartesian coordinate system offers the unique advantage that all three unit vectors, x, y, and z, are constant in direction as well as in magnitude. Unfortunately, not all physical problems are well adapted to solution in Cartesian coordinates.»

So I speculate the relationship shown in the OP's diagram may be displayed and subsequently read (from a printed) plot with higher accuracy in a curvilinear diagram than in one that is skewed (= straight axes), and even less in a cartesian coordinate system (= straight axes which are mutually perpendicular to each other).

This seems similar to nomograms, which may be based on scales parallel to each other (e.g., temperature in Celsius and Kelvin on one thermometer, other examples e.g., here), similar to a plot in a cartesian coordinate system. Or those used e.g., for vacuum distillations in chemistry to approximate the observed boiling temperature of a compound at a lowered pressure if both this adjustable lowered pressure, as well as the boiling temperature at atmospheric pressure are known; using curved scales. Despite their age, they are still in use today if a quick estimation with a ruler suffices:

(screen photo from the interactive tools by Sigma-Aldrich)

(The above nomograph visualizes the (integrated) Clausius–Clapeyron relation.)

I do not know if there are digitizers around to regain access to curvilinear diagrams.

[mszlazak]

@nbehrnd and @ankitrohatgi . Sorry guys but I am back to the image needing horizontal skewing to get the curves to work with orthogonal axes. But I could easily be convinced otherwise. LOL. Here are the before and after skewing pictures. The red dots should be vertical and all at the 2e-17 V/NBC value.

[nbehrnd]

@ankitrohatgi May you add, e.g. by an animated .gif a documentation how you suggest to deploy the digitizer for this type of plot? I recognize there is much value in diagrams like the ones shared as example by the OP. Simultaneously, I do not identify yet how to engage your program in a case like this.

@mszlazak I'm not yet convinced if WebPlotDigitizer may trade well with this type of plots. The obstacle, from my perspective, is that if the image is skewed to vertically align the red dots (or / and the blue ones I added)

are separated by some vertical space from each other. Because of the curvilinearity, however, the distance (in pixel units) between say the trace about 1 µ and 2 µ at 2e-17 V/NBC value are not the same as at the 2e-14 V/NBC value.

So I think one (tedious) approach is the manual read-out some of the data from the plot (trace 0.5 µ, trace 1 µ, ..., and trace 10 µ, each separately), followed by interpolation within these traces.

Of course, it would be useful if a digitizer could both read and interpolate for you. Tom O'Haver's open resource A Pragmatic* Introduction to Signal Processing mentions in Getting data into Matlab/Octave Matlab may natively / by add-ons (Data Thief and Figure Digitizer) access printed plots, too. I'm not familiar with either of them, nor with attempts to offer something similar to GNU Octave (e.g., this). Perhaps the audience of math.stackexchange may assist in identifying a pathway suitable here, because questions there may be tagged by «matlab» or / and «octave» specifically about these programs.

63_degrees.zip

[mszlazak]

@nbehrnd I don't see why the vertical distances be the 1μ and 2μ traces or any others, doesn't remain the same (to the resolution of a pixel). The horizontal skewing doesn't affect vertical distances.

[nbehrnd]

May it be that we read the same diagram differently?

So far I thought, the traces (0.5 µ, 1µ, etc) happen to be drawn at intersections of pF/mil^2 (left side scale, initially vertical, red) and the V/N_Bc (right hand scale, initially tilted, blue). And if this deskewing is applied that these traces look like strings of a guitar, with the then vertically aligned blue «frets», I notice that the distance between the strings is large on the bottom left, and small at the top right end of the figure. At some point, I'm unable to discern these traces as they seem to coalesce:

to_skew.svg.zip

[mszlazak]

@nbehrnd Yes if webplotdigitizer could do extraction with non-orthogonal axes then very close curves with a skew transformation wouldn't be an issue. Until then, a work-around could be to use separate plots for each curve before skewing but it's more tedious. BTW, my skewing of the original picture isn't exact but just to illustrate what's needed.

[ankitrohatgi]

Hi,

Looking into this in more detail only now.

WPD performs an affine transformation based on the four input calibration points and your plot involves shear along with the typical translation and scale parts of this transform. On first glance, I assumed it would just work since an affine transform would happily capture this mapping, but I see that the x-axis labels are actually along a line that runs perpendicular to the x-axis and not along a horizontal direction. Also y-axis labels are on a vertical line instead of the line in the sheared direction.

To get this right in WPD, you have to flip how you select X and Y axis labels in a possibly very unintuitive manner:

On doing this, the affine transform seems correct. Please feel free to verify in the project file.

skew.tar.zip

[ankitrohatgi]

If the placement of the four points seems hard to digest, then try thinking of this:

X1 and X2 should land on the same Y Y1 and Y2 should land on the same X

[mszlazak]

@ankitrohatgi

To get this right in WPD, you have to flip how you select X and Y axis labels in a possibly very unintuitive manner:

Terrific! Thanks for the technique.