So since I had some problems with VPhot to identify stars on wide field shots correctly, I progressed further to work around this inaccuracy, but I faced some other issues to have a smooth process.
Bugs:
- Highest prio: When I load a sequence and go to the "View Photometry Report", any changes is lost if I go back with "Back to Image", it will reset to the previously loaded sequence. This is annoying if I should do any changes e.g. to the check stars for the report: all manually selected stars after the sequence loading are lost in this case.
- Lower prio: Although there is a setting to import stars over a certain SNR, VPhot still import stars below this SNR threshold for Variable Star Index.
Feature requests:
- Copy the name of the non-identified stars easily. These are the stars which are marked red after a sequence or "Variable Star Index" is loaded. If it is too difficult to fix the star identification or drag-and-drop the falsely non-identified stars, at least copying the name should be easy. Currently, my only way is to click on the red circle which opens the Simbad search window where I can copy the name, go back to VPhot and add the star manually. But still sometimes the mouse pointer does not open Simbad, I had to add and delete a manual star first after the red star circles become clickable again. Manually writing a name is not trivial if it is an ASAS (or CSS) star.
Csaba,
Yes, changes made to the comp star sequence in the Photometry Report window are not applied to the sequence in the image window.
When you go "Back to Image", click the "X" next to the comp stars you want to remove. Then, when you go back and forth from the image window to the Photometry report window the new sequence will remain the same.
Once you have the edited sequence you like, including the check star and any targets you want to measure, "save" the sequence in the table of the image window. The next time you open an image for that target use your saved sequence rather the the AAVSO sequence for the photometry.
Phil
@spp
Hi Phil,
I did not express my problem better what you answered back. So my basic problem with VPhot that it can't identify the stars correctly because I work with wide-field DSLR shots (field size: 5.55x3.71) and the optical distortions paired with the resolution (5.14 arcsec/pixel) make VPhot's job hard.
So back to sequence loading. Obviously the sequence loading for new observations will also mostly fail because of the above reason and I have to add the interesting stars manually to correct the missed stars with "red circle". The problem comes that these changes are lost if I go back and forth between the photometry report. So in steps:
1. Load a new observation image.
2. Load a saved sequence. -> Several stars will be missed.
3. Add the missed stars by hand.
4. Go to photometry report.
5. Maybe realizing that something is wrong: e.g. I would need to change a comp. star to check star or delete a check star by any reason.
6. Go back to the image.
Expected: The previously added "missed stars" are still on the image. I would expect that it does not reset back all the time to the saved sequence when I go back to the image.
Outcome: The image resets to the saved sequence and all manual changes since the original sequence loading is lost.
Csaba,
Thanks for the clarification. I think I have a better understanding of your problem now.
Some questions:
Are your images plate solved by VPhot (pinpoint)? Have you tried using other software for plate solving?
Please explain what you do when you "add the missed stars by hand". (I think I know what you mean, but I'd like to be sure.)
I think it might be helpful if you would post one of your FITS images. (The forum doesn't allow FITS uploads, but you can work around this by zip or gz compressing the FITS.)
Phil
@spp:
> Are your images plate solved by VPhot (pinpoint)? Have you tried using other software for plate solving?
It is plate solved by offline astrometry.net. How can I try VPhot's pinpoint? I see the Update VCS, but when I click on it:
"At least one image in the batch needs to be plate solved (has WCS parameters)."
How should I use this feature with a standalone DSLR picture which is already calibrated and stacked?
I can convert to FITS and modify anything in the FITS header, but I am not sure about the requirements for "Update VCS". Especially since VPhot requires a correct FITS header before upload.
> Please explain what you do when you "add the missed stars by hand". (I think I know what you mean, > but I'd like to be sure.) I think it might be helpful if you would post one of your FITS images. (The
> forum doesn't allow FITS uploads, but you can work around this by zip or gz compressing the FITS.)
I already uploaded VPhot screenshots and a sample FITS to my other bug-report topic: https://www.aavso.org/detecting-variable-stars-fails-bit-vphot
Basically, the variable stars are missed by some pixels and marked with red circle. Since it is impossible to manipulate such "missed stars", I have to add each by hand again.
Csaba
Csaba:
You have identified a problem with plate solution of large fields of view from DSLR cameras. Distortions (field curvature?) may make plate solution inaccurate. So when the image gets to VPhot, the plate solution headers are not good enough to match with the expected RA/DEC for the comp in VPhot. The comp is outside the default search radius and the star is marked as unidentified (red circle).
Astrometry.net is a rigorous tool for plate solution. I do not think you should expect PinPoint to do any better? VPhot uses the same commercial stand-alone version of Pinpoint that many of us use off-line before uploading the images to VPhot.
I request that you not upload very large numbers of non-platesolved DSLR images to VPhot. Such DSLR images are very large (#pixels/bytes) image size and they dramatically slow the queue and lead to system failures? It is reasonable to upload a few to check this out.
However, to test a few existing images you might try the following:
1. Under Tools>Settings on an image page, increase the Search Radius to a larger value than the default 5. See if at some point the comps /targets are marked correctly (no longer a red circle)? This can lead to other incorrect identification problems due to nearby stars?
2. Did you save your sequence after you manually entered the correct positions? I assume you did! When you open this saved sequence for another image, the same radius search test occurs, so the failure to match occurs again and you get a red circle even with the corrected sequence? I think this is true BUT I have never tested this because I do not use a DSLR. (This is an item I am not sure I understand whether you have done already from reading above?)
I recommend that you share a few of these images to Phil (SPP) and me (MZK) so we can play around a bit. Also attach a few images to your post (as zipped). Perhaps we can find an alternative although I am not sure about this?
Ken
PS: I have not read all of your posts yet. I hope I am not missing some other obvious issue that Phil and you have already resolved?
Ken,
Thanks for jumping in. This is where I was headed when I asked about the astrometry software used.
Csaba,
I agree with Ken about the source of your problem. I think astrometry.net is more robust than pinpoint. For me it usually succeeds when pinpoint fails. So, I think you're unlikely to be able to use a fulled sized image in VPhot made with your current setup.
I'd be interested in what happens when you enlarge the search radius as Ken suggested. Here's an additional suggestion:
Use your currently loaded image in VPhot, but work within a smaller area around your target star. Select a sequence that stays within that smaller area. I'd probably start with a 15 or 20 arcminute radius and expand until the plate solution failure is apparent. Once you know how large a FOV you can use pick a longer lens that gives you that FOV.
Of course, if you're using a stationary mount you will soon run into trailed images. Perhaps you will find a "sweet spot" where your full image will plate solve well enough to use the whole image but you are still able to use the exposure time you need for your target without trailing. I don't use a DSLR so I don't know what is possible along these lines.
You will probably find good advice in the DSLR photometry forum.
Phil
I played with astrometry.net this weekend to find a setting which would solve my problem, but I could not figure out a solution. After browsing the internet, I found that the distortion correction in astrometry.net is quite experimental.
Bigger radius: it does not help, it will mostly still fail. And an obvious disadvantage of this setting that it can mark wrong stars what I want to avoid. It is better to fail than marking a false star.
I think this distortion problem is just not solvable in software easily. Instead can I ask to ease my repeated procedure with some small software modification in VPhot to speed up the manual correction of the failed stars? Quoting from my original post:
"- Copy the name of the non-identified stars easily. These are the stars which are marked red circle after a sequence or "Variable Star Index" is loaded. If it is too difficult to implement drag-and-drop the falsely non-identified stars, at least copying the name should be easy. Currently, my only way is to click on the red circle which opens the Simbad search window where I can copy the name, go back to VPhot and add the star manually. Manually writing a name is not trivial if it is an ASAS (or CSS) star."
Csaba
Hello!
Astrometry.net can create WCS in different formats. Typically (by default?) it creates a linear solution, i.e. celestial coordinates that correspond to reference pixel coordinates + coordinate increment in columns and rows (+ possible rotation etc). That's fine for long focal length instruments.
In your case, either Astrometry.net is creating WCS solution using TAN-SIP-type distortion correction by default or does that if you force to use non-linear WCS relation. To me, TAN-SIP seems to be kind of one of de-facto standards in current professional astronomy. There are also other possible ways how to represent optical distortions. E.g. quite widely used program Scamp uses different method (see: http://www.astromatic.net/software), definitely also one of de facto standards (or maybe even The One, according to FITS standard).
Now the issue is, that Pinpoint uses it's own (more or less proprietary?) method and Bob Denny is promoting that one. Yes, Pinpoint interprets correctly ordinary linear WCS-solutions (I don't know if all possible projections!), but at least couple of years ago discarded TAN-SIP or other distortion representations.
Please correct if I'm wrong, but I have impression that VPhot is relying on Pinpoint when doing WCS-related stuff. In that case there really are two principle ways (if not 3 ;-) ) how to proceed: first, use Pinpoint to solve your images; second, crop your images till linear approximation of WCS is good enough; third - I wouldn't bet on this :-p - convince Bob Denny to implement few other common distortion representations in Pinpoint + ask AAVSO to update VPhot to that Pinpoint version.
Tõnis
Csaba:
Unfortunately, the honest short term answer is that a programming change to VPhot will not likely happen in the near future. We are slowly working towards modifications to the VPhot code but it hasn't happened yet.
Ken
I have used VPhot with 12x8 degree DSLR images. Having said that, I substantially crop the images after platesolving (with astrometry.net via AstroImageJ). Getting the radii etc right can be fiddly but seems doable.
My remaining problem is to get good enough TCs (low error) with TG or spreadsheet method to use VPhot and TA as the last stage of my pipeline. Clusters are too small in my field.
Happy to provide more detail re: the steps, scripts and applications I've used, i.e. my current state of ignorance, successes and failures.
David
David,
That's very encouraging . I think you must have a high quality lens that produces images with small enough distortion to work with astrometry.net and VPhot.
RE: standard clusters for DSLR's. Have you tried using the Coma Cluster. I think that Arne worked to improve the photometry of the standard stars in this cluster last year. I've attached an image of a 5 degree chart (faintest stars set to 11 mag).
I don't think this cluster currently works with TG, so you'd have to use the spreadsheet method.
Phil
Thanks Phil. I use a 100mm f2 lens.
Nice re: coma cluster. Will have a look.
Although, from South Australia, the coma cluster only reaches a maximum altitude of around 27 degrees, e.g. mid Feb 2018.
Any other possibilities with a more southerly declination?
David
NGC 1252. I think this should work in VPhot. Attached is a 5 degree chart.
David: Please share your story!
Let's share my part. Currently, I am almost completely staisfied with my approach. I could automate almost everything in the pipeline. I have an unmodified Canon 1000D with Canon EF-S 55-250mm f4-5.6 IS STM lens. This lens was advised by a local astrophoto fellow who told that it has low distortion and chromatic error in the middle zoom range for a quite low price. I can confirm, it provides really "point stars", lightyears better than the factory Canon lens. So I use this lens in 200 mm, my field of view is 5.61x3.73 degrees. I use stacked images with usually 5 minutes of overall exposure. Normally, 10-20 variable stars can be measured in the field. In general, I can measure in the magnitude range ~8.5-11.7. On the edge of this range, the measurement error can go up to 0.05-0.08, but otherwise I usually get error below < 0.01-0.03. My whole pipeline is "automated", I capture the images with KStars, I stack with the command line interface of DeepSkyStacker, the image is plate solved by off-line astrometry.net and the FITS header in modified to be VPhot compiant with astropy.io (Python). Everything is scripted. I did not publish my scripts yet because I wanted to finish the whole process and my VPhot problem was the last remaining. As I can see that can't be solved thus I will put my scripts to Github in the near future with explanation.
Hello Kecsap and all
I do not do DSLR PT, only CCD, so I may be way off. But I would try pushing your lens to 250mm which is the max, which will reduce you field by about 25% and your area by 56%. It might reduce the fundamental amount of distortion at the edges. These two combined might make a better combo that would go thru Vphot/Pinpoint without hangup. Since your aperture does not change, this would not affect your exposures nor increase trailing. Depends on the design of your zoom, it might have an iris diphram in there which would change apterture slightly, but if its reasonable low cost, I would suggest not. It would not cost you any money either. Your images are not that much bigger than the BSM images. Arne, Ken, do BSM images plate solve with Pinpoint, or do we use something else?
Gary
WGR: I stepped back to 200 mm from 250 mm because the star shapes are too much distorted on the maximum zoom. I don't think 250 mm is a good alternative for this lens, I want to do a good (at least not bad) quality photometry.
On the other hand, I will try to determinate the distortion coeffitents of my lenses at 200 mm. I have some knowledge about camera calibration and how to determinate these numbers ard "undistort" an image. I just did not go in this way yet because I am just afraid to manipulate the image in a non-linear way which can alter the photometry.
mgw: Do you mean R or B color channels next to an R channel? If it is fine for you, I can easily extract all three for a given star field and upload to VPhot. As I mentioned, I have an unmodified Canon 1000D. That is what you want?
WGR: I stepped back to 200 mm from 250 mm because the star shapes are too much distorted on the maximum zoom. I don't think 250 mm is a good alternative for this lens, I want to do a good (at least not bad) quality photometry.
On the other hand, I will try to determinate the distortion coeffitents of my lenses at 200 mm. I have some knowledge about camera calibration and how to determinate these numbers ard "undistort" an image. I just did not go in this way yet because I am just afraid to manipulate the image in a non-linear way which can alter the photometry.
mgw: Do you mean R or B color channels next to an R channel? If it is fine for you, I can easily extract all three for a given star field and upload to VPhot. As I mentioned, I have an unmodified Canon 1000D. That is what you want?
Hi Csaba
I have mostly followed the approach taught by Mark Blackford in the first DSLR photometry course and the DSLR manual, but have started to add in the use of VPHOT, TG, and TA in more recent times.
I have a Canon 1100D (second-hand body) with a (new) EF 100mm f2.0 USM lens for wide field (12 x 8 degrees) as suggested by Mark Blackford when I asked about a suitable camera for DSLR photometry around the end of 2014. I don't have a lot of money to spend on equipment at the moment (my two teenage kids are pretty good at spending my money); I've been happy with the camera.
A local guy was building good quality light boxes so I bought one from him.
Being an advocate of open source, free software, I use free software for photometry too.
I use a Mac running IRIS via the WINE Windows emulator, converting RAW files to FITS.
I gave a talk a couple of years ago to my local astronomical society (ASSA):
https://www.slideshare.net/DavidBenn2/assa-imaging-group-dslr-photometry-talk-27-nov-2015
Starting from slide 14 will provide a simple overview of my low-tech, low-cost setup and approach.
I use the ensemble spreadsheet on the AAVSO website and submit B and V to AID.
Like you, I wrote a couple of Python scripts, in my case to help with FITS header mods etc. I should probably rename the GitHub repo to be something less pretentious. :) As an aside, I've converted them to Python 3 and will be committing those changes in the near future.
A few months back I started adding to my processing procedure: cropping, plate solving via AstroImageJ (which uses astrometry.net), and upload to VPhot for photometry, still using IRIS to perform calibration, stellar registration etc. Wide-field plate solving, even with the right amount of cropping, is still fairly fast.
I've used TG to create TCs as I mentioned in another reply and TA to apply them to VPhot results, but I haven't reduced the error enough to make use of this to submit observations to AID yet. As mentioned elsewhere, I need to use a more suitable southern standard star field/cluster.
Right now I write notes about my steps in a text file including details of commands run in IRIS or the shell. I like the idea of making use of a Jupyter notebook (see also https://www.aavso.org/photometry-astropy-photutils-reviewers-please).
What have I missed? Feel free to ask questions or make comments.
David
Nice! How do you calculate TA?
Gordon Meyers wrote TG (Transform Generator) the TCs (Transformation Coefficients) from which can be applied with TA (Transform Applier), written by George Silvis, to VPHOT output to yield transformed results.
David
Ah, ok. I can't use TA because I do ensemble observations. What was your experience with TR and TB observations? I tried to process a star field in TR and TB yesterday, but VPhot finds much less comp. stars for these filters than for TG. The error was too high (>0.1) and I given up.
I'm looking at adding an option to TG so any standard stars that can be downloaded in VPHOT can be used to generate transform coefficients. This would include the Coma Cluster.
I need wide field DSLR images in at least two filters for analysis and testing. Can someone share a few images via VPHOT? My userid is MGW
Thanks.
Gordon
Arbitrary standard star additions would be cool Gordon. I recall Mark Blackford making suggestions re: wide field standard star fields in an email thread several months ago.
David
WGR: I stepped back to 200 mm from 250 mm because the star shapes are too much distorted on the maximum zoom. I don't think 250 mm is a good alternative for this lens, I want to do a good (at least not bad) quality photometry.
On the other hand, I will try to determinate the distortion coeffitents of my lens at 200 mm. I have some knowledge about camera calibration and how to determinate these numbers and "undistort" an image. I just did not go in this way yet because I am just afraid to manipulate the image in a non-linear way which can alter the photometry.
mgw: Do you mean R or B color channels next to an R channel? If it is fine for you, I can easily extract all three for a given star field and upload to VPhot. As I mentioned, I have an unmodified Canon 1000D. That is what you want?
kecsap - I haven't worked with DSLR's. I assume you create separate FITS images for each filter and then upload these to VPHOT for processing. It's the single filter FITS images I need.
I mapped three images of AV Peg region on VPhot (B channel -> B filter, R channel -> R filter, G channel -> V filter) and shared with you.
I looked at Csaba's FITS image of the AV Peg region. Nice! Stars are reasonably sharp to the edges of the field. I see vignetting in this image; I don't see any calibration keywords in your fits header, so I'm going to assume that you have not flattened this image. You should revisit this important step.
Using DS9, which takes the astrometry.net WCS parameters, I can mouse over the image and compare coordinates. I highly recommend using DS9 for checks like these. For the subfield that correlates with the png file (basically the central degree or so), the variables and the AV Peg comparison star positions agree within a pixel or so, my cursor limit. So I think the astrometry.net WCS solution is good. I didn't bother checking the rest of the field, as problems appear within this first degree.
Since VPHOT obviously misses the variables, such as AV Peg itself, it is clear to me that VPHOT is either not interpreting the astrometry.net coefficients, or is applying them incorrectly. Tõnis' reply is spot-on; I'd talk to him more to see if you can find a simple solution. I'd also try David Benn's solution: crop your image to just that degree-sized region around AV Peg, and delete the existing WCS (since it will be wrong). Then let VPHOT's Pinpoint solve the image, and see if you get a matchup.
Note that the VPHOT display shows ALL of the variables in the field, even though many of them (such as the CSS variables) are too faint to appear on your frame. Be careful when reporting the results, as your big pixels and plate limit might give many false positives.
Congratulations on getting this far along! You are most of the way towards an automated pipeline. The BSM systems are sorta similar, with 1.4x2.2 degree fields, but are flat enough that linear WCS works fine and we don't get into these issues. APASS requires substantial optical distortion correction to handle its 3x3 degree fields. :-)
Arne
> I see vignetting in this image; I don't see any calibration keywords in your fits header, so I'm going to assume
> that you have not flattened this image. You should revisit this important step.
My images are calibrated, now I add field "CALSTAT BDF" manually to my new FITS files. The calibration field was missing earlier because I do the image stacking with DeepSkyStacker and it outputs TIFF file, not FITS. I "convert" the stacked TIFF file to FITS by plate solving, astrometry.net outputs a proper FITS file.
I know there is still some vignetting, but it is nothing compared to the original version. Obviously, I don't use the wrong image parts around the edges.
Thank you for your investigation regarding my coordinate issues! It is good to know that astrometry.net outputs good solving and the problem is in VPhot.
> I'd also try David Benn's solution: crop your image to just that degree-sized region around AV Peg.
I don't go in this direction because it multiplies the processing time for me for the same image and there are limited numbers of (recognized) comp. stars in the field.
Is it possible that this problem (bug) effects only "the Variable Star Index" loading? Because I usually get comp. stars recognized around the image. If the coordinates are so wrong, VPhot should not find the comp. stars on the image. So probably something is wrong with the coordinate calculation for VSX loading? Maybe not a huge implementation needed only fix a small bug somewhere.
> and delete the existing WCS (since it will be wrong). Then let VPHOT's Pinpoint solve the image, and see if you get a matchup.
I solved an image with Pinpoint yesterday and the result is not better in any way than astrometry.net. All of these things make me suspicious that the problem is only with VSX loading.
> Note that the VPHOT display shows ALL of the variables in the field, even though many of them (such as the CSS variables) are too faint to appear on your frame.
> Be careful when reporting the results, as your big pixels and plate limit might give many false positives.
I report only around 8-25 variables/picture in magnitude range 8.5-11.5 and before uploading a report, I have a simple script to query WebObs to verify if my observations are in an acceptable range. If it is not the case, I take a close look on VPhot/WebObs to find any problems.
> Congratulations on getting this far along! You are most of the way towards an automated pipeline.
Thanks!
Csaba
Arne, I couldn't agree more about DS9.
Actually, when a FITS file has WCS, it is very easy to overlay a catalog over it. It is especially convenient for WCS quality checking, because you see immediately when circular marks of catalog objects are not symmetrically (or even not at all!) placed over the stars. Inside DS9, starting from Analysis menu: Catalogs->Optical one can find many catalogs, including AAVSO (i.e. VSX)! Catalogs->'Search for Catalogs' allows to query from anything that is in Vizier catalogs.
Tonisee,
Thanks for the tip on displaying catalog information in DS9. Is there a way to show the APASS catalog?
Phil
Hi Phil,
I'm not sure if you can just query APASS from AAVSO using DS9. However, APASS magnitudes are used in UCAC4 catalog and that is listed under Optical section, too. I usually want both magnitude and it's uncertainty estimate, for that you can do like this:
If you want to click on object and see corresponding table row, select from DS9 main windows Edit->Catalog. Now if you click on marked object on image, table view jumps to correct row.
An alternative way (and sometimes can be more useful):
------------------------
If you click and/or move with up-down keys in the table, you see on image which star you have selected. I often just sort the table using RA2000 and scroll through appropriate section of the table (active marking on image will blink first and then stays highlighted).
If you also open Aladin, and then connect DS9 to SAMP hub (File->SAMP->Connect), send your image shown in DS9 to Aladin (File->SAMP->Image->Broadcast or Aladin), and then do exactly the same from Catalog tool window, you should have your image in Aladin and catalog overlay on it.
Now if you point your cursor to some object in Aladin (or select it by dragging a rectangle around it/them), corresponding table row in DS9 gets selected and image in DS9 centered on that object, too. Sounds somewhat complicated, but in reality it takes probably much less than reading that text here ;-)
--------------------------
If you create your own output from APASS database (which should be slightly newer and having slightly different values compared to UCAC4) in CSV format, you can open that table in DS9 Catalog tool or in Aladin. Actually, for tabular data, I'd suggest TopCat, it plays very well with others over SAMP and is much more table-oriented tool (i.e. more suitable for such task).
Tõnis
Tonis,
After your post #30 I did look at the UCAC4 magnitudes in DS9. I agree that it would be better to have more complete information, especially the magnitude uncertainties. I would and also like to know the number of APASS observations for each star.
It is possible to download the APASS data (in a specified radius around a specified set of coordinates) to a cvs file via the AAVSO web site . For me, at least as a first step, I would be very happy if I could just download the posted APASS data for a single image, then access that file to see the full APASS information in the DS9 table and the circled APASS stars in the image. How do I use the "Catalog Tool" to import the downloaded APASS data?
Phil
Hello Phil,
When Catalog tool is open, just File->Import->Tab-Separated-Value..., select your APASS CSV-file. You should see data in table section now. Select correct column names for RA and DEC (just above the table) - radeg and decdeg - and there you are.
Tõnis
It works! Thanks, Tonis.
Phil
While clearly not a "Critical" issue, I generally have qty 2 images in each of 3 or 4 bands that I need to stack. Instead of doing a separate stack per color, it would be great if I could just highlight all the files in all bands I want stacked at once and have VPhot examine and stack on a per-band basis. It would reduce my time per star by 20% I estimate.
Peter
BPEC
Good idea.
Thx
George
Here's another suggestion:
In some instances such as in Alert Notice 662 the researcher specifically calls out measuring a 2nd star not listed as a variable or comp star and reporting on it. In 662, the star mentioned is seen in images. I can't seem to find a way to save it as a "target star" with the appropriate name (2MASS J16194990-1537248), I can only save it as "Star 1". If we take requests like this, I would think we should support them or not take them.
Peter
BPEC
Peter:
If I followed what you tried to do, I was successful. You can easily edit the target name from Star 1 to 2MASS J16194990-1537248 or other. We could skype?
Ken
Now that I play with…
Ken,
Now that I play with it a bit more, I've gotten it to work. Yesterday I guess I just didn't work long enough with it.
Will there be any consequences in saving the data with WebObs given that 2MASS J16194990-1537248 isn't in the database as a variable or comp star??
Peter
Answered my own question. Works fine in WebObs, probably because the 2MAss name is an alternate of a recognized NSV name...