-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Image file formats support in arkimet #277
Comments
in RMAP I use https://github.com/r-map/rmap/blob/0ef0ce01ecf0e88b7530e1d09cc303fa53db473e/python/rmap/exifutils.py#L153 The dimensions I think are not usefull metadata too. I use imagedescription to identify the provider of image (is the only standard exif metadata I found usefull for this) but is possible to change it. So I suggest those minimal metadata for arkimet: those are the linked exif metadata:
|
In @brancomat example we have also altitude -> station height, although that's not usually metadatum (using
|
for the webcam network we need other metadata.
|
Do you expect to need to have a dataset with hybrid image formats, like |
I'd say no. |
Ok, perfect. Mixing different formats in the same dataset would require a significantly more extensive redesign work |
We have initial JPEG support:
The scanning script is in Most of the pieces should be there to start a JPEG dataset. We now need real-world test samples to fine tune the scanner, and see if the existing metadata types are ok or we neeed to add new ones |
@spanezz can you describe the metadata ? |
I don't know if we have ever compiled a complete census of all metadata available in arkimet: the variety grew quite organically. It may be time to do it, and it's a non trivial amount of work that would warrant its own ticket. Can you (plural you) confirm that we don't have that documentation, and it's not that we actually have it and I cannot find it, and then open a ticket asking for it? |
Coming back to a previous message
Why can't we use
as it is done for BUFR stations (although it says GRIB)? |
I ask for JPEG only dataset.
which "existing metadata types"? |
see above:
|
Good catch. I pushed the change, now it's the same as with BUFR |
The scanner for JPEG datasets can generate any metadata value that is used by all other scanners: arkimet doesn't have a concept of format-specific metadata. Sometimes the name of a format makes it to metadata values, like in
I mean all the metadata available in arkimet for all other formats: can they be reused to describe everything needed for a JPEG, or do we need to create new ones? That's not something that we can answer up front, I think, and we'll see as we start putting real world data into a dataset, and figuring out what are the aspect of those data that we want to be able to query with arkimet |
Questi metadati potrebbero essere tra gli standard:
Per quanto riguarda il livello, mi sfugge perché le informazioni GPS non possono essere usate:
Rimarrebbero, a quel punto, solo |
@pat1 te la riassegno per una review. |
secondo me per compatibilità con tutto il resto e per indiscussa versatilità del sistema WMO e inoltre l'altitudine usata come riferimento non mi è chiarissimo come usarla. Ma se è conforme usarla come:
ma secondo me essendo da GPS si intende tutt'altro. Channel nelle immagini pare abbia un altro significato lo sostituirei con "spectral band" o sinteticamente "band"
oppure:
|
Ok, allora manteniamo il level dentro allo UserComment così siamo a posto.
Sul channel benissimo tramutarlo in band, ma io non ho idea di cosa si stia parlando, quindi scegli pure tu quali valori usare. Non ho invece capito se
Possono andare bene oppure vogliamo metterli come metadati custom camera_pan, camera_roll e camera_tilt? |
LONG è definito come 32-bit (4-byte) unsigned integer il che è già un problema perchè bisogna inventarsi una rappresentazione unsigned.
quindi direi non c'entrano nulla con il nostro caso. |
Per me va benissimo |
Siete dei maghi! Aggiungo solo che la classificazione VIS, VIR,... SLW mi pare più adatta per definire la banda perché pare orientata alle applicazioni fotografiche e affini, mentre l'altra classificazione è più fisica, e la banda effettivamente usata potrebbe essere "a cavallo" tra 2 definizioni; però parlo un po' a sentimento. |
Le spefiche sono state trasmesse alla ditta che dovrà generare i file JPEG. Attendiamo, per il proseguimento del lavoro, un file di test da parte loro. @spanezz ti avviso non appena me lo inviano. |
Assegno la issue a @pat1 (si veda e-mail "Tag EXIF per progetto camERa" di oggi) che dovrebbe verificare la correttezza dei tag EXIF nei file JPEG che la ditta ci sta mandando per poterteli poi passare. |
Allego le specifiche v0.1 del progetto camERa Progetto camERa_ specifiche EXIF tag - v0.1.pdf. Per ora, i metadati che sono sicuramente da implementare sono:
@pat1 allegherà poi dei file JPEG di esempio per la test suite. |
Nomenclatura file riportata qui per comoditàTelecamere
ProdottiST rappresenta il codice telecamera
|
Allego immagini di esempio. innagini.zip
|
visti i dati forniti dalla rete Camera propongo i seguenti adattamenti alle specifiche di codifica: distinzione canale visibile tra RGB eBW nella tabella per camera_band:
aggiunta del metadato "postproc" nel json del UserComment con i seguenti valori:
|
Correzioni da apportare alla codifica di UserComment: Valorizzare se possibile:
Timerange:
Level:
|
Allego la versione 1.0 delle specifiche Progetto camERa - specifiche EXIF tag v1.0.pdf |
Con i file allegati nello zip a: |
As discussed in other fora, arkimet capabilities should be extended for archiving and indexing image file formats (i.e.: webcam outputs).
As a starting point it shoud support:
A minimal set of metadata to index could be:
Sample image: test.tar.gz
It would be nice if the resulting scanner could be accompanied by some documentation, to facilitate independence in metadata extensions / edits.
(this is a working draft, open to suggestions)
The text was updated successfully, but these errors were encountered: