Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Rich <rich@example.invalid>
Newsgroups: comp.os.linux.misc
Subject: Re: Most Straight-Up Way to Retrive COMPLETE JPGs in OpenCV Environment
Date: Thu, 29 May 2025 15:15:39 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 41
Message-ID: <1019tmr$3u5kp$1@dont-email.me>
References: <Z_-cnaub1Jjobar1nZ2dnZfqn_adnZ2d@giganews.com>
Injection-Date: Thu, 29 May 2025 17:15:39 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="cd1912e51e4e489dd66cfdd7995f4fd7";
	logging-data="4134553"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18I4FWCnuiLpPY8poWHgh2y"
User-Agent: tin/2.6.1-20211226 ("Convalmore") (Linux/5.15.139 (x86_64))
Cancel-Lock: sha1:du6up0BSDoggAFlxlvtFMDhvcuk=

c186282 <c186282@nnada.net> wrote:
> MOST of my JPGs come from SECURITY CAMS.  They get refreshed, by the 
> cam, about once per second.  Good enough.
> 
> But, problem, it's kinda pure CHANCE as to whether I get a COMPLETEL 
> jpg.  The cams may update at any moment.

The problem here is a classic race condition.  Your 'file reading' 
program is not synchronized with the 'file writing' program (the cam) 
and so it is opening files the camera has not yet finished writing.

Some ideas for solutions:

Can you configure the camera to write to separate jpeg files (i.e.  
0000.jpeg, 0001.jpeg, etc.)?  If yes, then you could ignore the 
"newest" file (as it might still be getting written) and only open the 
"second newest" and older files instead.

If the camera always writes to the same file (this is a poor design, 
but if it is what the camera does and you can't change it you have 
little recourse) then what filesystem does the camera write to?  Is it 
a Linux filesystem?  If yes, you /might/ be able to use an inotify 
event of "file closed" to synchronize your reader to the writer such 
that the reader only reads the file just after the camera closed it 
(assuming the camera wrote a complete file, then you'd get a 1 second 
chance to read the file whole).  If you go this route I'd suggest you 
simply do a straight "file copy" when the inotify event triggers, then 
open and process that copy.  That gives you "1 second" to complete the 
copy (fesable) and your "after processing" can take more than 1 second 
without worry at that point.

Third idea, if your cameras provide a "web" api to retreive the current 
image, maybe retreving an image via that method to use might give you a 
fully valid image.

> Clearly though, OpenCV isn't entirely oriented towards securing 
> COMPLETE jpgs.  It acts on WHAT'S THERE at the moment.  MIGHT be 
> complete, or maybe not.

Not really OpenCV's fault when the file it is reading is incomplete.